Flipkart payment reconciliation: match orders, settlements and bank credits

A Flipkart payout can match the bank while still containing an unexplained transaction. Equally, a sale without a payment in the same calendar month is not automatically a missing-payment claim. A useful reconciliation therefore answers two questions separately: does the payment agree with the bank, and can the underlying order-item activity be explained?

This guide is an operating method, not a statement of universal Flipkart payment terms. Use your own Seller Hub reports, applicable agreement and case records for amounts, eligibility and deadlines. The worksheet fields below are recommended working columns, not a promise that every export uses those exact headings.

1. Define the payment and the reporting cut-off

Start with one completed payment statement and its corresponding bank entry. Record the seller account, currency, payment reference, payment date, export time and reporting period. Keep a separate order cohort if you also want to assess which orders remain unpaid; a payment-period review and an order-period review have different boundaries.

Collect the payment statement, relevant order-item records, return records, fee documents and any adjustment or claim decisions. Preserve the downloaded files unchanged. Work in copies and keep a small import register containing each filename, selected filters, date range, row count and control totals.

Before matching anything, check:

• Whether the export covers all required locations and the intended seller account.
• Whether the selected dates refer to order creation, a return event, a transaction or a payment.
• Whether amounts include tax, and whether the sign convention makes deductions negative.
• Whether every requested report finished generating and every page or file was included.
• Whether opening exceptions from earlier periods need to be carried into this review.

Flipkart's Returns API reference distinguishes creation-date filters from modification-date filters and documents pagination. This does not mean a Seller Hub spreadsheet has the same interface; it explains why an API-fed workflow must record its filters and follow every subsequent page. A successful first response alone is not a completeness check.

2. Match at order-item level without multiplying amounts

Keep the order ID, order-item ID, SKU, shipment reference and quantity in separate columns where available. Flipkart's shipment lookup documentation defines an order-item ID separately from the order ID, SKU and shipment ID. It also records quantity and whether an item is a replacement. These distinctions matter when several items share one order or several transactions refer to one item.

Use the most granular shared identifier supported by the actual files. Do not join on SKU alone: the same product can appear in many purchases. Do not force a blank or unmatched item ID onto the nearest sale based only on amount and date.

Preserve transaction rows before grouping

An order item may need several financial lines to explain it. Keep those lines intact, then create a separate item-level summary. If you join a detailed payment file to a detailed return file directly, repeated identifiers on both sides can multiply rows and inflate totals.

Before and after each join, compare row counts and signed amount totals. Investigate unexpected increases rather than deleting rows until the result looks right. Preserve account-level adjustments that have no item reference in a separately controlled bucket; allocating them arbitrarily to one SKU hides the uncertainty.

Check overlapping exports, not just identical rows

Two downloads with overlapping periods can contain the same transaction. Keep the source filename and source-row number, and use a documented transaction identifier where provided. If no unique transaction identifier exists, flag possible duplicates using the available combination of item reference, transaction type, date and amount, then inspect them.

Identical amounts are not sufficient grounds for deletion: two legitimate fees can look similar. Record every exclusion and retain the original row so another person can reproduce the result.

3. Rebuild the statement total and match the bank

Translate the statement's amounts into a documented signed convention: credits positive, deductions negative. Sum the included financial lines and compare the result with the statement's stated payment amount. Resolve differences in report coverage, signs, opening balances or account-level entries before treating the reconstructed total as complete.

Then match the statement to the bank using reference, currency, amount and dates. If several bank entries appear to belong to one statement, or one credit appears to cover several references, retain the evidence for that grouping. An equal amount alone is a candidate match, not a confirmed match.

Illustrative arithmetic, not a rate card

Assume a hypothetical completed statement contains sale credits of ₹12,000, a refund deduction of ₹1,000, fees and other deductions of ₹1,800, and a confirmed adjustment credit of ₹200. Its reconstructed net is ₹12,000 − ₹1,000 − ₹1,800 + ₹200 = ₹9,400.

If the bank credit is ₹9,400, the transfer agrees. That does not establish that the ₹1,800 was correctly charged. If the bank credit is ₹9,300, the ₹100 difference remains unresolved until its cause is documented; it is not automatically recoverable revenue. These figures are invented solely to demonstrate the calculation and are not Flipkart tariffs or Steps Ecommerce results.

Do not subtract a refund twice merely because it appears in both the return record and the payment statement. Use one financial source for the amount and the other record as supporting evidence.

4. Reconcile return events separately from financial credits

A return status is an operational event, not by itself proof of a refund, fee reversal, inventory receipt or bank credit. Track each outcome separately and connect it using the references that your actual records provide.

Flipkart's official return reference distinguishes customer returns from courier returns. Keep that distinction in the working ledger instead of labelling every returned shipment as RTO. Record replacements separately where indicated; do not assume a replacement means a second paid sale.

For each affected item, check the original sale entry, financial reversal or refund, retained charges, any later adjustment, and the physical stock outcome. Record a credit that is expected but not yet confirmed as pending. Do not use an anticipated claim approval to make the payment reconcile.

When a later statement contains a credit for an older transaction, link it back to the original exception and retain both dates. For delivery-failure cost analysis, use the separate RTO guide and retained-cost worksheet; this payment review is about explaining financial entries, not estimating a universal return-loss percentage.

5. Check fees against the terms effective for the transaction

Build an expected-fee calculation only from documented terms and verified transaction attributes. Save the applicable fee schedule, programme conditions and relevant evidence with its effective date. Check the item category, fulfilment arrangement, measured weight or zone where relevant, and the transaction's return or cancellation treatment.

Do not copy a competitor's fee percentage or payment timetable into the audit. If a required attribute or rate is missing, mark the calculation incomplete rather than treating the unknown as zero. Separate a modelling estimate from a verified charge comparison.

Keep deductions, tax components and credits traceable to their source documents. A difference between sales and the payout is not automatically a marketplace expense or a tax error. Ask a qualified accountant to confirm the accounting and tax treatment where needed.

The linked Marketplace Fee Calculator can help explore a scenario, but it does not validate a statement or replace the terms that applied to the order.

6. Maintain an exception ledger with closure evidence

Use a ledger that preserves both the original question and the final resolution. Recommended columns are:

• Seller account, payment reference and source filename.
• Order-item ID, order ID and related return or adjustment reference.
• Transaction date, payment date and review cut-off.
• Expected amount, recorded amount, signed variance and calculation basis.
• Exception category, evidence location and missing information.
• Assigned owner, next action and applicable deadline verified in the account.
• Case reference, outcome, confirmed credit reference and closure date.

Useful working categories include unmatched bank entry, incomplete source data, timing difference, duplicate-import candidate, fee question and return-adjustment question. These are internal triage labels, not official Flipkart dispute categories.

Close an item only when the explanation or financial correction is evidenced. A submitted ticket is not a recovery, and a displayed approval is not the same as a matched credit. Where a decision rejects the claim, preserve that outcome and the reason; do not leave it in a recovered-money total.

7. Review coverage before reporting recovery or profit

Finish with three controls: the statement-to-bank match, the transaction-level matching coverage, and the open-exception balance. Report the number of records assessed and the exact period, not just a percentage without a denominator.

Separate unresolved differences, submitted claims, approved adjustments and credits actually matched. Avoid netting unrelated positive and negative exceptions into a reassuring zero. Review older unresolved items as well as new ones, and carry forward their original references without counting them twice.

Reconciliation is also not a complete profit calculation: product cost, advertising, inventory write-offs and other business costs require their own records. A correctly matched payout can still come from an unprofitable order.

For a handover, keep the unchanged exports, import register, matching rules, effective-date terms and exception ledger together. Our Reconciliation & Recovery service, linked below, provides the operational handoff; the scope should specify the review period, required data, responsibilities and evidence needed to close an exception.

Source review and practical limits

Reviewed on 18 October 2026. The linked Flipkart developer references display no publication or revision date in their accessible page text. They support identifier and return-data definitions, not a universal Seller Hub export layout, current tariff, payment deadline or claim entitlement.

The controls and worksheet in this guide are our recommended working method. Confirm the current account interface and applicable policies before acting, restrict access to financial and buyer data, and share only the records needed for the agreed review.