Payment reconciliation is the process of matching every sale you recorded against the money you actually received, line by line, and explaining each difference. For an ecommerce business it runs across four systems at once: the marketplace settlement, the payment gateway, the courier’s cash on delivery remittance, and the bank.
Most sellers treat it as a bookkeeping formality. It is closer to an audit of the platform. Roughly every gap you find falls into one of seven categories, and only three of them are money you can get back.
What is payment reconciliation?
Payment reconciliation is a control that compares recorded sales against received funds and accounts for every difference between the two. It confirms three things: that each completed order was paid for, that each deduction taken was correct, and that every tax withheld has been credited to you.
It is not the same as bank reconciliation. Bank reconciliation matches your cash book to the bank statement and stops there. Payment reconciliation goes a level deeper, from the bank credit back to the individual orders that produced it and the fees taken along the way.
For a retail shop the two are identical, because ₹1,180 billed is ₹1,180 received. For an ecommerce seller they are not, because ₹1,180 billed arrives as roughly ₹985 in a lump credit fourteen days later, mixed with other orders, minus fees and minus two taxes.
Why payment reconciliation matters in ecommerce
Without reconciliation, an ecommerce business cannot tell the difference between a sale that was never paid for and a sale that will be paid next cycle.
Three consequences follow, and they get progressively more expensive. First, unrecovered deductions: commission charged above the category rate and freight charged on an inflated weight slab go unnoticed because nobody checks them per order. Second, unclaimed tax: GST TCS and income-tax TDS withheld on your behalf stay unclaimed unless someone accepts them on the respective portals. Third, wrong books: the profit figure a founder runs the business on is built from the wrong revenue number.
There is a deadline attached to the third one. Input tax credit for a financial year cannot be claimed after 30 November following the end of that year, or the date of the annual return, whichever is earlier, under Section 16(4) of the CGST Act. A reconciliation run in December for the previous financial year finds the gap and cannot fix it.
The four reconciliations an ecommerce business runs
Each one answers a different question and they must be run in sequence, not in parallel.
Reconciliation | What is matched | Answers |
|---|---|---|
Marketplace settlement | Order and tax reports against the platform settlement file | Was each order settled, and were the fees correct? |
Payment gateway | Gateway settlement report against prepaid orders | Did the gateway release what it collected, net of its charges? |
Cash on delivery | Courier remittance statement against dispatched COD orders | Did the courier remit the cash it collected? |
Bank | Net credits against all of the above | Did the money actually arrive? |
Run them in that order. Marketplace and gateway reconciliations clear the bulk of your order volume quickly, which leaves a small, meaningful residue in the COD file where the real losses hide. Bank reconciliation comes last because it is only useful once you know what each credit is supposed to be.
The payment reconciliation process step by step
Fix the period as a full calendar month, never a settlement cycle or payout window.
Download the order or tax report from every sales channel for that month.
Download the settlement or remittance report from every platform, gateway and courier.
Extend the settlement download by 15 days on each side to capture cross-period orders.
Build one row per order ID, carrying gross value, expected fees and expected taxes.
Match settlement rows to order rows on order ID, not on amount.
Aggregate multi-row settlements, since one order writes several fee lines.
Classify every unmatched or variant row into one of the seven gap types below.
Recover what is claimable and write off what is not, with a reason recorded.
Post the month’s fees, taxes and adjustments to the books from the reconciled file.
Carry forward unresolved items into next month’s opening position.
Step six is where most manual reconciliations fail. Matching on amount looks faster and produces false pairs immediately, because dozens of orders in any month share the same value. Order ID is the only reliable key.
What goes in a payment reconciliation report
A usable reconciliation report is one row per order with the expected figure beside the actual figure and the variance calculated.
Column | Source | Purpose |
|---|---|---|
Order ID | Order report | The matching key |
Order date and settlement date | Both reports | Identifies timing gaps |
Gross order value | Order or tax report | Revenue for books and GST |
Expected commission | Category rate × gross value | Baseline for fee variance |
Actual commission | Settlement report | Compared against expected |
Freight charged | Settlement report | Compared against declared weight slab |
Tax withheld, GST TCS | Settlement report | Tied to the portal credit |
Tax withheld, income tax | Settlement report | Tied to Form 26AS and AIS |
Net expected against net received | Calculated | The variance |
Gap type | Assigned | Decides whether to claim, wait or write off |
Status | Assigned | Open, claimed, recovered or written off |
The last two columns are what separate a reconciliation from a spreadsheet. Without a gap type and a status, the same unresolved order gets re-investigated every month by whoever is doing the file that time.
How payment gateway reconciliation differs
Payment gateway reconciliation is simpler than marketplace reconciliation because the gateway takes one deduction rather than eight, but it carries two problems of its own.
The first is refunds. A gateway processes a refund on its own timeline, which is often a different month from the one in which you issued the credit note. Under Section 34(2) of the CGST Act, a credit note reducing your output tax liability has to be declared by 30 November following the financial year of the original supply, so refunds drifting across a year end need watching.
The second is chargebacks and failed captures. An order marked paid in your system where the capture failed at the gateway will sit as a receivable forever unless the reconciliation catches it. Gateway charges carry GST, and that GST is input tax credit, so the fee has to be split into charge and tax rather than booked as one net amount.
How B2B payment reconciliation differs
B2B payment reconciliation matches invoices to receipts where the two rarely correspond one to one, which makes the order ID method useless.
A B2B customer pays three invoices with one transfer, deducts TDS, takes a settlement discount and short-pays a disputed line. The reconciliation therefore runs on invoice reference and remittance advice rather than on amount matching. Two additional checks apply: the TDS deducted has to agree with Form 26AS and the Annual Information Statement, and credit notes for rate differences and returns have to be applied before the balance is treated as overdue.
Ageing is the output that matters here, not variance. A B2B ledger reconciles perfectly and still hides the fact that ₹14 lakh of it is 120 days old.
The seven gap types and what each one means
Every difference you find belongs to one of these. Classifying it correctly is what tells you whether to act, wait or stop.
Gap type | What it is | Action |
|---|---|---|
Timing | Order settled in a later cycle | Wait. Self-clearing |
Return | Platform processed a return you did not book | Book it |
Fee variance | Commission above the category rate | Claim |
Weight variance | Freight charged on a higher slab than declared | Claim |
Tax withheld | TCS or TDS deducted but never accepted or claimed | Claim on the portal |
Missing payout | Delivered order never settled at all | Claim. Highest value |
Unlinked adjustment | Reimbursement, penalty, ad spend or storage with no order ID | Book to its own ledger |
Three of these are recoverable as claims against the platform: fee variance, weight variance and missing payout. One is recoverable from the government: tax withheld. The other three are accounting corrections rather than money you get back.
The distinction matters because teams waste weeks chasing timing gaps, which resolve themselves, while missing payouts sit unnoticed. At month end, timing gaps commonly account for the largest count of unmatched rows and close to none of the recoverable value.
What tolerance to set and when to stop chasing
Reconciliation without a materiality threshold never finishes, because rounding alone guarantees small variances on every order.
Our recommended thresholds for an Indian marketplace or D2C seller are these. Treat a fee variance as noise below the greater of ₹1 or 0.5% of order value. Investigate any single order variance above ₹200 regardless of percentage. Investigate any gap type whose aggregate for the month exceeds 0.25% of gross settlement value, even where each individual row is immaterial. Write off the residue once total unexplained variance falls under 0.1% of monthly settlement, and record that write-off rather than letting it vanish.
These are working thresholds, not a legal standard. Set them once, write them down, and apply them the same way every month. A threshold that moves according to how much time the team has is the same as having none.
One exception overrides all of them. Never write off a tax withholding difference, however small, because that is not your money being lost to rounding. It is a credit sitting on a government portal with your name on it.
Where payment reconciliation meets GST
The reconciliation file is the evidence behind three GST positions, and the department can check all three.
Your declared turnover has to agree with what the marketplace reported about you in GSTR-8, which the operator files by the 10th of the following month. Your input tax credit on platform fees has to agree with GSTR-2B, generated on the 14th, which in turn depends on what you actioned in the Invoice Management System before the 13th. And the GST TCS withheld from you has to be accepted under “TDS and TCS Credit Received” on the portal before it reaches your electronic cash ledger and becomes usable.
None of those happen automatically. Detailed workings for each sit in our guide to ecommerce accounting basics for Indian sellers and the companion piece on GST returns for marketplace sellers.
Records behind the reconciliation are not optional either. Section 36 of the CGST Act requires books and supporting records to be retained for 72 months from the due date of the annual return, and settlement files are the support for every fee and tax entry in your books.
Where reconciliations break down
The failure is almost never the maths. It is the process around it.
Reconciliation gets run on the payout cycle rather than the calendar month, so it never ties to a GST return period. It gets run quarterly, by which time timing gaps and real gaps are indistinguishable and the claim windows on the platform have closed. Unresolved items get deleted rather than carried forward, so the same order is investigated four times in a year. And the file gets rebuilt from scratch each month by a different person, with different column names, which makes any trend analysis impossible.
The fix is dull and it works. One format, one owner, one calendar month, run within ten days of month end, with unresolved rows carried forward as an opening balance.
Need this run every month across your channels? Talk to Ashish’s team at Complylocal Consultants about payment and marketplace reconciliation services.
Platform-specific steps, report names and Excel formulas are covered separately in our guide to Amazon and Flipkart payment reconciliation.
