Myntra Reconciliation: Matching Sales with Payments

Reconciling marketplace sales with received payments is a routine but critical task for marketplace sellers and finance teams. When settlements arrive from Myntra, they often differ in structure and timing from internal sales reports, creating exceptions that must be resolved before close.

This article shows a practical approach to reconcile Myntra sales with payments using an AI-assisted reconciliation engine. It explains required data, matching logic, common exception patterns, and a repeatable implementation you can adopt for monthly or periodic settlement cycles.

The primary goal is to reduce manual ticking and produce audit-ready reconciliation results that finance teams can review, explain, and export.

Why this topic matters

Marketplace settlements combine orders, refunds, platform fees, and chargebacks into periodic statements. Without a clear reconciliation process, finance teams face:

• Unexplained payout variances and disputes with the marketplace.
• Delays in recognizing revenue or applying correct fee accounting.
• Time-consuming manual matching of thousands of rows during settlement reviews.

A structured reconciliation workflow helps teams close books faster, surface root causes (refund timing, fee misclassification, partial settlements), and give leadership reliable data to act on.

Core components

A reliable reconciliation requires predictable inputs, configurable matching logic, and clear outputs. Break the reconciliation into these components and align them to your Myntra workflow.

Data sources: Side A and Side B

• Side A (internal): sales ledgers, ERP order exports, order-management CSVs, or accounting entries. These are the records your business expects to be correct.
• Side B (external): Myntra settlement reports, marketplace payout files, payment gateway or bank statements capturing actual inflows.

Identify the primary identifier used by your operations (order ID, settlement ID, invoice number) and capture it consistently on both sides where possible.

Data preparation and mapping

• File formats: use CSV, XLS, or XLSX for uploads. Confirm header row and map date, amount, and identifier columns during setup.
• Supporting data: upload product masters, fee rate files, or refund logs to enrich primary reports without directly reconciling them. Supporting data helps calculate net amounts or map partner-specific IDs to internal IDs.
• Derived columns: create calculated fields (for example, net payout = settlement_amount - platform_fee) with formulas generated from natural language where supported. Derived fields can be used for matching or output columns.

Matching logic: rule-based then AI

1. Rule-based matching: the engine first applies deterministic rules using identifiers, exact amounts, and date windows. This handles high-confidence one-to-one matches and straightforward grouped matches.

2. AI-assisted matching: transactions that are structurally different or missing identifiers are analyzed by AI to suggest likely matches based on description similarity, amount balancing, and timing. AI prioritizes high-confidence matches and flags low-confidence cases for manual review.

Matching modes supported include one-to-one, one-to-many, many-to-one, many-to-many, net-to-net, contra matching, and partial matching where amounts differ.

Outputs and review statuses

Reconciliation outputs should clearly categorize each line:

• Fully matched: identifiers and amounts reconcile according to configured logic.
• Partially matched: identifiers align but amounts differ and require investigation.
• Unmatched: present on one side only.
• Skipped: invalid or incomplete records excluded from runs, with a visible reason so teams can fix upstream data.

Export audit-ready reports that include matched pairs, unmatched items, and any manual matches so reviews and audits have full traceability.

Common matching scenarios for Myntra reconciliation

Understanding typical exception patterns helps prioritize fixes and tailor matching rules.

Scenario: Settlement lines are summarized

Myntra payouts often roll multiple orders, refunds, and fees into a single settlement row. Use grouped or net-to-net matching to reconcile multiple Side A orders against one Side B settlement, ensuring total amounts balance within allowed tolerance.

Scenario: Order IDs missing or reformatted

Identifiers may be truncated, padded, or include partner prefixes. Use identifier normalization (strip special characters, trim spaces) and similarity matching as a fallback. Supporting master files that map partner IDs to internal order IDs reduce reliance on fuzzy matching.

Scenario: Partial payments and refunds

Partial matches occur when refunds, chargebacks, or fee corrections adjust amounts. Treat these as partially matched and surface them as exceptions for accounting adjustments.

Scenario: Timing differences

Settlement dates and order dates often differ. Allow configurable date windows (days or periods) during matching; prioritize amount and identifier signals over exact date equality.

Practical implementation steps

1. Gather files: export your internal sales/order report (Side A) and Myntra settlement and payout files (Side B) in CSV/XLS/XLSX formats.

2. Configure the reconciliation template: upload one representative file for each side and map header row, date column, amount column, and primary identifier column(s).

3. Add supporting data: upload fee rate files, refund logs, or product/customer masters to enrich records and enable accurate net calculations.

4. Define derived columns: create formulas for net payout, fee allocations, or conditional amounts (for example, ignore canceled orders) so matching uses the correct numeric fields.

5. Standardize and clean: normalize identifiers, trim whitespace, convert date formats, and standardize currency/amount formats before running matches.

6. Run rule-based matching: let the deterministic engine perform high-confidence matches (exact identifiers, amount equality). Review counts of fully matched and skipped records.

7. Review AI suggestions: for remaining transactions, review AI-proposed matches and accept, reject, or perform manual matches where necessary. Use filters to focus on high-impact exceptions (largest amounts, most frequent SKUs, or top merchants).

8. Document manual matches: any manual matches should include a reason and be reversible. Annotate partial matches so accountants know whether an adjustment or customer refund is needed.

9. Export and automate: export audit-ready reconciliation reports and supporting CSVs. If the workflow is recurring, save the template and enable scheduled uploads or API automation to run future reconciliations without reconfiguration.

Common mistakes to avoid

• Relying on date equality alone; matching should prioritize identifiers and amounts, with flexible date windows.
• Not uploading supporting data; missing fee or refund files leads to avoidable exceptions.
• Forcing low-confidence AI matches; always surface uncertain matches for manual review to avoid incorrect accounting entries.
• Ignoring skipped records; they often point to upstream data quality issues that need fixing.
• Not saving reusable templates; reconfiguring the same reconciliation each period wastes time.

Key Takeaways

• Align internal sales (Side A) and Myntra payouts (Side B) by standardizing identifiers, amounts, and dates before matching.
• Use rule-based matching for high-confidence matches and AI for complex, unstructured exceptions.
• Add supporting data and derived columns to calculate net payouts and reduce false exceptions.
• Categorize results as fully matched, partially matched, unmatched, or skipped and keep manual matches auditable.
• Automate once the template is stable to remove repetitive manual work and speed period-end close.

Conclusion

A consistent Myntra reconciliation approach cuts review time, improves accuracy, and produces audit-ready outputs that finance teams can trust. Start by standardizing your inputs, build a reusable reconciliation template, and combine deterministic rules with AI-assisted matching to resolve exceptions quickly.

Start your 14-day free trial with Cointab. No credit card required. 14-day free trial.