Tally Bank Reconciliation for Marketplace Payouts
Bank reconciliation is where marketplace accounting either proves itself or falls apart. The bank statement shows a stream of odd-valued credits from Amazon, Flipkart and Meesho; your TallyPrime books should contain a receipt voucher matching each one to the paisa. When they match, the whole chain upstream — sales, returns, fees, TCS — is implicitly verified. When they do not, the BRS becomes a monthly archaeology dig. Here is how to keep it on the easy side.
Why marketplace payouts break naive BRS
- Net amounts. A payout is sales minus fees minus TCS — it matches nothing in your sales register directly, only a properly built receipt against the party ledger.
- Frequency. Platforms settle on rolling cycles; a busy seller sees many credits per month per marketplace.
- Merged and split payments. One bank credit can cover multiple settlement IDs, and occasionally one settlement arrives as two credits.
- Holds and reserves. Amounts withheld this cycle release in a later one, shifting cash timing away from settlement timing.
The setup that makes BRS one-to-one
The rule from our settlement receipts guide does most of the work: book one Receipt voucher per actual bank credit, debiting bank and crediting the marketplace party ledger, with the settlement ID in the narration. Then TallyPrime's reconciliation screen for the bank ledger is a simple matching exercise — each statement credit finds exactly one voucher. Set the bank date on each entry as you match, and the unreconciled remainder tells you precisely which payouts are booked but not yet landed, or landed but not yet booked.
Name the bank ledger cleanly and keep marketplace inflows in the operating account you actually reconcile — sweeping payouts through multiple accounts before they rest multiplies the matching work for no benefit. If you must receive different marketplaces into different bank accounts, keep the receipt convention identical across them so the routine transfers from one account to the next without retraining anyone.
Working the reconciliation screen
- Open the bank ledger's reconciliation view for the period.
- Match marketplace credits first — they are the bulk of an e-commerce bank account.
- For every statement credit without a voucher: the settlement was never imported, or the receipt was merged with another. Fix in the books, not with a plug entry.
- For every voucher without a statement credit: payout booked from settlement data but not yet received — normal within a cycle, suspicious beyond one.
- Investigate residuals immediately; they only compound.
Watch the direction of your fixes: every unmatched item is resolved by correcting the books to reflect reality, never by editing reality to match the books. Plug entries and forced adjustments are how small differences metastasise into an unreconcilable ledger by year end. If a difference resists explanation for more than a cycle, escalate it to whoever owns the marketplace account — occasionally the platform itself has misposted, and the paper trail from your BRS is exactly what the support ticket needs.
Reserves, holds and paisa differences
| Situation | Treatment |
|---|---|
| Platform holds part of a settlement | No entry needed — the amount simply stays in the party ledger until released and paid |
| Released reserve arrives with a later payout | One receipt for the actual bank credit; narration lists both settlement references |
| Paisa-level difference between settlement and credit | Book to a rounding ledger; investigate anything beyond paise |
| Refund clawed back after payout | Adjustment flows through the party ledger via the next settlement's entries |
None of these cases needs heroics — they need the party ledger respected as the single meeting point between settlement data and cash, which is the quiet theme of this whole guide.
A weekly routine beats a monthly ordeal
Fifteen minutes weekly: import the week's settlements, book the receipts, match the bank, and note anything unmatched with a date and a suspicion. Differences are days old and memorable, not weeks old and mysterious. The prerequisite is that settlement processing keeps pace — which is exactly what TallySutra automates. It converts each Amazon, Flipkart and Meesho settlement report into the complete voucher set with one receipt per payout, reconciled against the report's own totals before your CA approves the batch; the Gateway posts approved batches to Tally, duplicate-safe, so a re-downloaded report never doubles a receipt. Sellers running this loop report the pleasant version of BRS: open the screen, match, done. See the reconciliation features and the broader workflow for sellers and CAs.
Frequently asked questions
Why does my Amazon payout not match any sales figure in my books?
Because it is a net amount — sales minus returns, fees and TCS. It should match a receipt voucher against the marketplace party ledger, not a sales total. If no such receipt exists, the settlement was not fully booked.
One bank credit covers two settlement IDs. How do I book it?
One receipt voucher for the exact bank credit amount, with both settlement IDs in the narration. Keeping receipts one-to-one with bank credits is what keeps reconciliation mechanical.
How should I treat amounts the marketplace is holding in reserve?
Leave them as balance in the marketplace party ledger — they are receivables not yet paid. They need no special entry; the receipt happens when the release actually reaches your bank.
TallySutra turns Amazon, Flipkart and Meesho reports into reconciled, reviewed TallyPrime vouchers — duplicate-safe, with every rupee traceable to its source row.
Book a 30-minute demo