Begin with the statement rather than a dashboard sales total
Select the shop, currency and statement-date range in Finance > Statements. The official report guide distinguishes the statement view from the order view, which can show all statements associated with an order. Use the exported file as a preserved source and add working calculations separately.
Record statement ID, date, status, settlement amount and payout or payment reference. Use the account's current field definitions: interface labels can change, and the report guide contains inconsistent summary notation for adjustment signs. Preserve each signed transaction instead of hard-coding every adjustment as a deduction.
Know which question each record answers
The statement explains an aggregation of settlement events. The order rows explain the sales, fees and adjustments behind it. The payment record explains an attempted or completed movement of funds. One cannot substitute for the other merely because they share an amount.
Keep order creation, delivery, statement and payment dates where available. The EU finance policy defines settlement timing relative to delivery, with account-dependent periods. A product may already be delivered while the proceeds are still awaiting release.
| Record | Primary question | Useful matching key |
|---|---|---|
| Order / SKU | Which sale and costs generated this amount? | Order ID + SKU + event |
| Statement | Which events were grouped into a settlement? | Statement ID |
| Payment | Which transfer was initiated? | Payout / payment ID |
| Bank entry | Which transfer arrived and in what amount? | Bank reference + currency + date |
Illustrative statement bridge with a later payment
Assume the selected statement contains €1,000 net sales, €80 shipping deductions, €120 fees and a signed positive €15 adjustment. The expected settlement is €815. These are invented figures on the platform report basis, not tax-exclusive accounting revenue.
If the payment is still processing, an €815 statement can be internally reconciled even before the bank credit appears. If a later payment combines or references other statements, use its actual mapping rather than assuming a one-statement-to-one-bank-entry relationship.
Illustrative settlement = €1,000 − €80 − €120 + €15 = €815Investigate a missing or different bank amount
Check the payment status and reference first, then the currency and bank date. A pending, processing or failed status answers a different question from whether the fee arithmetic was correct. Do not book a second sale when the same order reappears in a later adjustment.
For a difference, separate timing, missing records, duplicate imports, signed adjustments and currency effects. Keep unresolved amounts in an exception list with the originating IDs; a generic Other number cannot explain a recurring settlement problem.
- Prove the statement's detail adds to its total.
- Match the statement to the recorded payout or payment.
- Check transfer status and the actual bank reference.
- Identify the difference as timing, amount, currency or missing linkage.
- Retain supporting rows and resolve the exception without changing raw data.
What should be automated after the manual process works?
Automate retrieval and repeatable matching only after the record relationships are understood. The useful controls are completeness, duplicate detection and visible exceptions. A system that produces a neat total while dropping unlinked refunds is less reliable than a small reconciled workbook.
Retain a way to rerun the period when later adjustments arrive. The operational question is not whether yesterday's export can be reproduced exactly, but whether each new event can be added without rewriting or duplicating the earlier ones.