Reconciliation for a digital goods business means proving that three records agree: your own order log, the codes that were delivered, and the supplier’s statement of what you were charged. When all three match, the books close; when they do not, a mismatch that shows up nowhere else in the business has just surfaced.
That last part is the reason to reconcile daily rather than monthly. Digital goods mismatches are quiet by nature: no shipment goes missing, no customer complains, the money just leaks.
Why quiet mismatches happen
Each of these has happened to every operation running API orders at volume:
- A retried order that bought twice. A timeout, a retry without an idempotency key, and the supplier sold you two codes while your log shows one order. Nothing errors; you were charged twice.
- A failed delivery nobody noticed. The order completed and was charged, but the delivery email bounced or the webhook was missed. The customer never received the code and never complained, or complained through a channel that did not connect the dots.
- A price that moved between quote and charge. Your log records the quoted price; the statement records the charged one. Small drifts per order, invisible until summed.
- A replacement credited but not recorded. The supplier replaced a dead code or issued a credit, and it exists on their statement but not in your system.
None of these appear in uptime monitoring or support metrics. They appear in reconciliation or not at all.
The daily routine
- Match by order ID, line by line. Pull yesterday’s orders from your log and the same period from the supplier’s statement or transactions API, and join them on the order reference. Aggregate totals hide the mismatches you are looking for.
- Investigate every orphan within a day. A statement line with no matching order, or an order with no statement line, gets a name next to it and an answer within twenty-four hours. Orphans age badly: a week later, nobody remembers the incident that explains them.
- Track prepaid balance movement. Opening balance, minus fulfilled orders at charged prices, plus top-ups and credits, should equal the closing balance. This catches whole classes of error that line matching misses.
- Close each period formally. Write down that the day (or week) reconciled, who checked it, and which exceptions were carried forward. A period nobody closed is a period nobody checked.
Log the right things at order time
Reconciliation is only as good as the records you kept when the order happened. At order time, log your request ID, the idempotency key you sent, the quoted price, the supplier’s order reference from the response, the delivery timestamp, and a code reference such as the supplier’s code ID or a hash.
Never the code itself. Codes are bearer instruments and logs are the least protected place in most systems; the integration guide treats this as a hard rule, and reconciliation needs a reference, not the secret.
Log failures with the same discipline. A failed order with the provider’s error code recorded is a five-minute orphan investigation; the same order without it is an afternoon. The error field guide covers which failures leave which traces.
Frequently asked questions
How do I reconcile API orders with a supplier statement?
Join the two datasets on the order reference: your order log on one side, the supplier’s statement or transactions export on the other, line by line rather than by totals. Every matched pair should agree on price and status. Anything unmatched on either side is an orphan and gets investigated individually, ideally within a day of appearing.
How often should reconciliation run?
Daily for the line matching, with a formal close at least weekly and always at month end. Daily matters because orphans are cheap to investigate while the context is fresh and expensive once it is gone. Balance tracking can run continuously: a prepaid balance that moved without a matching order deserves an alert, not a report.
What causes mismatches in digital goods reconciliation?
The usual suspects: a retried order that purchased twice, a completed order whose delivery quietly failed, price drift between the quoted and the charged amount, and supplier credits or replacements that were never entered in your system. All of them are silent, which is why they surface in reconciliation and nowhere else in the business.
What should I log at order time for reconciliation?
Six fields: your request ID, the idempotency key you sent, the quoted price, the supplier’s order reference from the response, the delivery timestamp, and a code reference such as the supplier’s code ID or a hash. Never the code itself, since logs are the least protected place in most systems. With these fields recorded, an orphan takes minutes to explain instead of an afternoon.
What is an orphan in digital goods reconciliation?
An orphan is a record with no counterpart: a statement line with no matching order in your log, or an order with no line on the supplier’s statement. Each one gets a named owner and an answer within twenty-four hours, because orphans age badly; a week later, nobody remembers the incident behind them. Common causes are duplicate purchases, missed deliveries and unrecorded supplier credits.