Two records of one capture make an order look overpaid by its own value

Classification runs on identifiers. Two versions of one basket show up as a single order identifier carrying two totals, or as a total that moved between one export and the next ^[8]. Split captures reconcile one by one: a 150 euro order captured as 100 and then 50 ^[9], which is 150 exactly ^[22]. Double counting shows up as two records pointing at the same operation identifier from two different sources ^[13]. The fourth class has nothing to point at, because the record is simply absent ^[16].

The size of the gap tells you nothing about which one you have. The post's opening example is an order at 120.00 euro against a capture of 119.40 ^[2], a shortfall of 60 cents ^[23]. Its basket example is 30 euro apart, and both exports are telling the truth ^[7]. A spreadsheet compares totals, and all four classes produce a total that does not match ^[19].

The dangerous one is the double count. The provider reports a capture, the ledger reports the same capture, and adding them makes the order look overpaid by exactly its own value, so somebody starts preparing a refund ^[11]. "This one is dangerous because it doesn't look like a duplicate, it looks like a finding," the author wrote ^[12].

The repair for that class is a decision. Decide once which source is authoritative for each kind of record, and write it down somewhere people can find it ^[13]. No comparison can settle it, because the data cannot say which system to believe ^[14].

For the absent record, the first step is finding out why it is absent ^[16]. The causes the post lists are a webhook that failed and was never retried, a nightly export that ran while a transaction was still in flight, and a refund issued from the provider's dashboard that the order system never heard about ^[15]. "A missing record isn't a discrepancy to reconcile, it's a hole in how two systems talk to each other," the author wrote ^[17].

What the post asks of a comparison tool is refusal. Two basket versions and no rule for choosing between them: say so, do not pick the bigger one. If two sources claim one payment, report that both are claiming it, do not add them up. And when a record is missing, say it is missing, do not treat it as a zero ^[20]. A green result then means one narrow thing, that the records supplied are consistent with each other; it says nothing about whether the money arrived or whether the provider's history is complete ^[21].

The taxonomy is one practitioner's account across banking, healthcare, gaming and public administration, where every team was sure its situation was unusual ^[5]. The post does not count incidents beyond the twice-a-month figure ^[1]. Whether the four classes appear in your ledger in anything like these proportions depends on preconditions you can check: class two needs a provider that does partial captures and retries after a decline ^[9], class three needs provider events and your own writes landing in the same comparison ^[11], and class one needs an export that snapshots a mutable basket without saying which version it is ^[8]. A shop that captures once per order, and lets one system write payment records, should expect the fourth class and little of the other three ^[25].