How to Reconcile Myntra Sales vs Payment Reports

Reconciling marketplace sales against payment or settlement reports is a routine but often painful monthly task for finance teams. Myntra sellers and finance operations frequently face mismatches caused by refunds, fee deductions, split settlements, timing differences, and inconsistent identifiers.

This guide explains a practical, repeatable approach to reconcile Myntra sales vs payment reports efficiently. It combines careful data preparation, rule-based matching, and an AI-assisted final pass so teams can reduce manual effort and produce audit-ready outputs.

The primary focus is on building a process you can reuse every settlement cycle: standardize files, create derived columns where needed, run deterministic matches, review AI-suggested matches, and resolve exceptions.

Why this topic matters

Marketplaces like Myntra send settlement files that often differ in structure and granularity from an internal sales ledger. A single order in your sales report might be split into multiple payouts, or a single payout may aggregate many orders. Without a repeatable reconciliation process, gaps multiply and month-end closes slow down.

Good reconciliation protects cash accuracy, helps identify missing payouts or duplicate refunds, and reveals process issues with order or return flows. For CFOs, controllers, and finance managers, faster reconciliations free time for analysis rather than manual ticking and tying.

Core components

Sound reconciliation rests on four core components: clearly defined Side A and Side B datasets, robust data standardization, layered matching logic, and enriched supporting data.

Side A and Side B

• Side A (internal): your Myntra sales ledger or order export containing order IDs, sale amount, item-level data, return and fee flags, and accounting codes.
• Side B (external): Myntra settlement or PSP payment reports containing settlement IDs, payout amounts, settlement period, deductions, and timestamps.

Be explicit about which file is Side A and which is Side B before you start. Consistency enables repeatable mappings and reporting.

Data standardization and mapping

• Normalize date formats and timezones so settlement dates align with your accounting periods.
• Trim and standardize identifier fields (order ID, txn ref, settlement ID) to remove extra characters or inconsistent prefixes.
• Convert currencies and ensure amounts use a consistent sign convention for payouts versus sales.

Practical tip: map header rows and column types on upload. If a file deviates from the configured format, surface clear errors so the source team can correct the export.

Matching logic: rule-based then AI-assisted

Start with deterministic rules that offer high precision and traceability:

• Exact identifier match (order ID to settlement reference) with equal amounts is the strongest signal.
• Date plus amount window matching handles cases where identifiers are missing.
• Grouped matching (one-to-many and many-to-one) handles split settlements and aggregated payouts.

After rule-based matching, use AI-assisted matching for the stubborn 10-20 percent of records where identifiers are inconsistent, descriptions vary, or partial amounts suggest related transactions. AI should suggest likely matches but never invent data or force matches where totals do not reasonably balance.

Supporting data and derived columns

Supporting datasets are powerful:

• Upload fee schedules, return reports, or mapping tables to explain settlement deductions or to link marketplace SKUs with internal SKUs.
• Create derived columns to compute net payable, fee-adjusted amounts, or conditional amounts (for example, treat orders with status Returned as zero for payout matching).

Derived columns let you express business logic once and reuse it each cycle.

Practical implementation steps

1. Collect reports

• Export your Myntra sales/order report and the Myntra settlement or PSP payout file in CSV/XLS/XLSX.
• Gather supporting files like return logs, fee breakdowns, and mapping tables.

2. Configure the reconciliation

• Upload Side A and Side B files and select header row, date, amount, and identifier columns.
• If multiple identical-format files exist, upload them under the same report configuration to avoid reconfiguration.

3. Standardize columns and create derived fields

• Normalize date formats and amount signs.
• Create derived columns for net payable, fee-adjustments, or conditional amounts based on order status.
• Use supporting data to enrich missing order details and to map party-specific IDs to your internal IDs.

4. Run rule-based matching

• Execute deterministic rules: exact identifier matches, date+amount windows, and grouped netting for aggregated settlements.
• Review the high-confidence matches and export a preliminary matched ledger for reference.

5. Run AI-assisted matching for remaining items

• Allow the system to analyze unmatched records and suggest likely matches based on similarity, amount patterns, and contextual signals.
• Review suggestions and accept or reject. AI suggestions should be treated as proposals, not automatic finalizations.

6. Manual review and exception resolution

• Investigate partially matched records, focusing on refunds, chargebacks, or fee differences.
• For unmatched items, check for timing differences, skipped or invalid records, and missing supporting files.
• Apply manual matches only when totals reconcile and document the rationale in notes.

7. Export audit-ready reports

• Produce matched, partially matched, unmatched, and skipped reports for auditors and stakeholders.
• Save the reconciliation configuration so the same workflow can be reused for the next period.

8. Iterate and automate

• Identify recurring data issues at the source and fix exports where possible.
• Where reliable, schedule automated uploads or API-based feeds to remove manual file transfer.

Common mistakes to avoid

• Failing to standardize identifiers before matching; small format differences cause large mismatch volumes.
• Ignoring supporting data; fee and return files often explain most mismatches.
• Over-trusting AI suggestions without human review when amounts do not reasonably balance.
• Manually matching without proper documentation; manual matches should be reversible and auditable.
• Treating every unmatched item as a problem; sometimes timing differences or withheld settlements explain gaps.

Key Takeaways

• Reconciliation succeeds when Side A and Side B are standardized and derived columns reflect business logic.
• Use deterministic rules first, then run an AI-assisted pass for ambiguous or messy records.
• Supporting data and mapping tables dramatically reduce exceptions by explaining fees, refunds, and aggregated settlements.
• Save configurations and automate reliable inputs to shorten future cycles.

Conclusion

A repeatable Myntra sales reconciliation process turns a monthly scramble into a controlled, auditable workflow. Apply consistent data mapping, use derived columns to represent business rules, run rule-based matches, and review AI suggestions before finalizing exceptions to keep reconciliations efficient and reliable.

Start your 14-day free trial with Cointab (https://cointab.ai/). No credit card required. 14-day free trial.