Marketplace settlement reconciliation: explain every rupee before raising a claim
How should a retail brand reconcile marketplace settlements?
Reconcile marketplace settlements by matching order-line events, refunds, charges and adjustments to a settlement period, then matching the resulting payout to the bank receipt. Separate amounts not yet due from unexplained differences. Preserve each source reference, classify exceptions, assign an owner and close a case only when the supporting correction or payment is recorded.
Begin with the money movement you need to explain
A marketplace settlement is a collection of financial events. It is not necessarily the value of orders placed that week. The operating question is therefore specific: which transactions were eligible for this payout, which deductions or adjustments changed it, and what actually reached the bank? Start with one seller account, one currency and one settlement identifier before combining channels.
Keep commercial performance separate from cash reconciliation. A healthy sales week can produce a smaller payout because refunds relate to earlier orders or some balances remain outside the payout. Conversely, a reimbursement can increase cash without representing a new sale. Neither observation proves a problem until you reconstruct the relevant events.
Build three connected records
Use an order-line record for what was sold, a financial-event record for money movements and a bank record for cash received. Preserve the platform's original identifiers alongside internal identifiers. One order line can have several charges, a partial refund and a later adjustment; flattening everything into one mutable row can hide that history.
Amazon's settlement documentation lists order, settlement, posting and amount-classification fields. That illustrates why an event ledger is useful. Availability and naming differ across marketplaces; the workflow below is a recommendation for evaluation, not a claim of a standard connector.
| Record | Minimum information | Control question |
|---|---|---|
| Order line | Account, order, line, SKU, quantity | What commercial event occurred? |
| Financial event | Event reference, amount, currency, type, date | Why did the balance change? |
| Settlement | Period, payout reference, included events | Which events became payable? |
| Bank receipt | Value date, amount, reference | Was the payout received? |
Reconcile in a sequence that preserves evidence
- Archive the original exports with retrieval time, account and file checksum or version.
- Check currency, sign conventions, duplicate references and the stated reporting period.
- Map financial events to order lines where a valid reference exists; retain legitimate account-level items separately.
- Rebuild the settlement total using signed amounts and separately identified opening or closing balances where applicable.
- Match the payout to the bank using reference and amount, allowing documented timing differences.
- Investigate unmatched items without changing source records to force agreement.
A repeated import should not create repeated deductions. Use a stable source event identifier when available. Where it is absent, define a composite matching rule and flag ambiguous collisions for review rather than silently deleting similar rows.
Worked hypothetical example: a smaller deposit
Assume a simplified settlement has ₹2,00,000 of eligible merchandise proceeds, ₹15,000 of refunds, ₹30,000 of fees, ₹5,000 of reimbursements and ₹10,000 newly retained outside the payout. All values use a consistent illustrative basis; taxes and opening balances are excluded for this example.
Expected payout is ₹2,00,000 − ₹15,000 − ₹30,000 + ₹5,000 − ₹10,000 = ₹1,50,000. The bank receives ₹1,48,000, leaving ₹2,000 unexplained. The entire ₹52,000 difference between proceeds and bank cash is not leakage: ₹50,000 is explained by the ledger.
Create a ₹2,000 exception with its settlement reference. If evidence later identifies a legitimate adjustment, classify it accordingly. If a subsequent credit resolves it, link that credit to the original case; do not count the credit as another new recovery opportunity.
Separate timing from disagreement
A useful exception queue distinguishes missing reference, amount mismatch, duplicate event, unexpected fee category, unreceived payout and balance carried forward. Give each category a different next step. A timing gap calls for an expected release or value date. A contractual disagreement calls for the applicable term and its effective date.
Amazon India's pricing page separates several fee categories. Do not infer that one headline commission rate explains every charge. Verify the category, price, fulfilment method and applicable period against the actual account evidence before disputing a fee.
Avoid calling every debit a loss or every pending case recoverable. Record disputed amount, supported claim amount and cash recovered as separate measures. A claim submitted is an operational milestone, not a realised financial result.
Put ownership and age on every exception
Assign an operations owner for delivery evidence, a catalogue owner for classification and a finance owner for settlement closure. One accountable case owner should coordinate those dependencies. Capture the original amount, reason, evidence link, next action, due date and final disposition.
Measure unmatched value as a percentage of the financial-event value in scope, while also showing the absolute rupees and event count. Track case age from first detection and distinguish internal waiting time from external response time. Large amounts and approaching documented deadlines deserve attention, but repetitive small errors may reveal a broader control weakness.
Practical close checklist
Before marking a period reviewed, confirm that every file expected for the account arrived, all currencies reconcile independently, and the payout is linked to a bank record. Review account-level adjustments, reused references and unexplained carry-forwards. Ensure accepted differences carry approval and a reason, while unresolved cases remain visible in the next period.
Ask a second reviewer to reproduce one matched order and one exception from source documents. A process that only its creator can explain will be fragile when staff, report formats or marketplace terms change.
Evaluate the decision interface with a real sample
Bring a redacted settlement, order export and bank receipt to a marketplace workflow walkthrough. Ask how a proposed Fundle Brain view would show the source event, calculation, uncertainty and accountable next action. The acceptance test is an explainable reconciliation with known coverage, not an unexplained single score.
Questions from retail teams
Why can order value and payout differ even when nothing is wrong?
Orders, delivery eligibility, refunds, charges and bank receipt dates can fall in different periods. A payout can also include adjustments unrelated to new orders. Rebuild the settlement from its included financial events before comparing it with the bank. Comparing the bank deposit directly with booked orders mixes commercial activity with cash timing.
What should we do with charges that have no order ID?
Retain them as account-level events until their nature is established. Some charges legitimately apply to a period, service or adjustment rather than an individual order. Record the source reference and classification, then decide whether an allocation is useful for management reporting. Never invent an order match just to make every row look complete.
How do we prevent duplicate recovery claims?
Create a case key from the seller account, source event or adjustment reference, reason and disputed amount. Check both open and closed cases before submission. Link later credits to that case and preserve partial recoveries. A re-exported deduction should update evidence for the existing investigation rather than create another claim.
Should finance close a case when the marketplace approves it?
Record approval as a separate stage. Financial closure should follow the organisation's policy and include the actual credit or payout evidence, including any remaining difference. Keep approved but unpaid cases visible with an expected next event. This prevents operational approval from being reported prematurely as cash recovered.
Can reconciliation start without an API integration?
Yes. A controlled export process can establish the matching rules, source coverage and exception categories before any automation investment. Record file versions and retrieval dates, restrict access and test repeat imports. A later integration should reproduce those controls and expose failures; its availability must be verified for each account and platform.
Sources and further reading
- Amazon Selling Partner API: Settlement Reports — Documented settlement fields and V2 amount classifications; broader reconciliation workflow is editorial recommendation.
- Amazon India: Fees and Pricing — Documented fee categories and category/price/fulfilment dependence; hypothetical amounts are not platform rates.
