Find revenue discrepancies by comparing the full financial lifecycle of each order: payments and captures minus refunds and chargebacks, against AFAS invoices and credit notes. Comparing gross daily totals can let two opposing errors cancel out and does not identify which order is still missing a financial document.
Why separate totals provide false reassurance
Suppose one refund is missing and another order is posted twice for the same amount. The daily total may reconcile exactly while both customer records are wrong. Payment, settlement, invoice and credit may also occur on different days or even in different months. Reconciliation therefore needs to follow order identity and lifecycle, with an explicit as-of date for each source.
Calculate a technically expected net amount for every order from the supported payment events. Compare it with the sum of linked AFAS documents under the model approved by the accounting team. Keep “source not refreshed yet”, “document still within the normal delay” and “substantive discrepancy” as separate outcomes.
Reconciliation table per order
| Check | Sources | Example signal |
|---|---|---|
| Gross lifecycle | WooCommerce and payment provider | Missing or duplicate capture |
| Adjustments | Refunds and chargebacks | Refund paid but not posted |
| ERP documents | AFAS invoice and credit note | Document missing beyond the agreed age |
| Lifecycle net | All linked events | Net discrepancy outside tolerance |
| Provenance | Identities and execution register | Ambiguous or manual match |
Only use amounts after identities have been verified. A coincidentally equal total is not a match. Connect can bring source events and AFAS results together in the same technical check.
Fictional example: the net amount only reconciles after a late credit
Fictional example: order LN-502 from lighting shop Noorderlicht was paid for 240 euros. A portion of 40 euros is refunded. The expected lifecycle net is therefore 200 euros. The AFAS invoice for 240 euros is already available, but the credit note only appears the next morning. The first reconciliation shows “waiting for credit within the agreed window”, rather than immediately declaring a definitive financial incident.
After the next source refresh, the credit is linked and the order reconciles at 200 euros. LN-503 also has a refund of 40 euros, but a credit is still missing after the configured age, and the technical execution register shows no initiated credit posting. That order receives targeted attention. This example is fictional and does not determine which periods or postings are financially correct; it illustrates how lifecycle and age together reduce noise.
Make discrepancy reasons actionable
- Paid and settled, no AFAS document: check the order route and execution intent.
- Refund present, no credit: investigate the refund and credit steps separately.
- Lifecycle net differs: compare captures, refunds and linked documents.
- Bank transfer underpaid: have the accounting team determine the policy and next step.
- Orphan invoice in AFAS: search for the source identity in a controlled way, not by amount alone.
- Source not yet current: refresh first and avoid a premature correction.
Show in Desk which check needs attention on the order, without exposing financial details to unauthorised roles. The technical foundation of order identity is described in reliably integrating an online store and ERP. Have the accounting team approve financial definitions, tolerances and time frames.
Design the period selection deliberately. A September report must still link an October refund to the original order, while also showing that the adjustment occurred in a later reporting period. Retain the transaction date as well as posting and settlement times. Let users choose an as-of date and show when each source was refreshed. Otherwise, a discrepancy can appear resolved or new simply because one API is five minutes behind.
Do not use discrepancy amounts as the only priority. A small recurring difference across hundreds of orders may matter more than one large timing difference that has already been explained. Rank by reason, age, number of affected orders and possible next step. Sample “closed” lifecycles and trace every identity back to the source; this tests matching as well as the calculation. When an employee accepts a discrepancy, retain the reason and scope of validity. A rounding tolerance must not silently conceal a missing refund as well.
Create a separate category for AFAS documents without a linked webshop order. Do not automatically match them by amount; use fixed references and a bounded list of candidates. This keeps manual postings and migration records visible without forcing them onto the wrong order.
Want to explain discrepancies per order instead of only comparing totals? Develop lifecycle reconciliation with Yindle.