Nykaa Fashion Marketplace Reconciliation with ERP
For brands selling on Nykaa Fashion, reconciliation often means comparing marketplace orders, settlements, deductions, returns, and payouts with internal ERP records. When those records do not line up, finance teams have to spend time tracing missing orders, amount differences, and settlement gaps across multiple reports.
Cointab helps finance teams structure this work as a repeatable Nykaa Fashion marketplace reconciliation with ERP. Users upload Side A and Side B reports, map key fields such as order ID, amount, date, and reference numbers, and run reconciliation using structured matching logic. The result is a clear view of fully matched, partially matched, unmatched, and skipped records, along with an audit-ready Excel report.
Why Nykaa Fashion reconciliation with ERP becomes difficult
Marketplace data usually reaches finance teams in separate files and at different times. One report may show the order, another may show the settlement, and a third may show deductions, returns, or payouts. Internal ERP data may use different identifiers or a different level of detail.
This creates common reconciliation issues:
- Orders appear in the marketplace report but not in ERP.
- ERP entries exist, but the corresponding marketplace record is missing.
- Order value and settlement value do not match exactly.
- Returns, cancellations, fees, or deductions change the net amount.
- The same transaction needs to be traced across multiple reports.
Cointab is designed to make this process transparent. Finance teams can see what matched, what did not match, and why a transaction may still need review.
How Cointab structures this reconciliation
Cointab uses a Side A and Side B model for all reconciliation workflows.
Side A: your internal records
Side A contains the records your business expects to be correct. For a Nykaa Fashion workflow, this often includes:
- ERP sales exports
- Internal order reports
- Ledger entries
- Receivables or settlement working files
- Supporting master data such as product or SKU mapping
Side B: Nykaa Fashion marketplace records
Side B contains the records received from the external source. For this use case, this may include:
- Nykaa Fashion order reports
- Nykaa Fashion sales reports
- Settlement or payout reports
- Return or deduction reports
- Related bank receipt data when needed
The reconciliation setup can be reused for future periods, so teams do not need to rebuild the same logic every month.
Reports typically used in the workflow
The exact report structure may vary by business process, but most teams reconcile a combination of these files:
| Report type | Typical purpose |
|---|---|
| ERP export | Internal source of truth for sales, invoices, or accounting entries |
| Marketplace order report | Order-level activity from Nykaa Fashion |
| Sales report | Marketplace sales values and item-level details |
| Settlement or payout report | Net amount paid after deductions and adjustments |
| Return or deduction report | Refunds, returns, fees, charges, or other adjustments |
| Bank statement | Confirmation of received payouts, when required |
If a report uses a different format in a later period, the configured file format validation can flag the mismatch so the team can fix the input before reconciliation continues.
What Cointab can identify
After the files are uploaded and the required fields are mapped, Cointab applies structured matching logic to compare both sides. Finance teams can review the results by transaction and by summary bucket.
Fully matched
These are transactions where the identifiers and amounts match according to the reconciliation logic. They can be closed quickly with less manual review.
Partially matched
These are records where the identifiers match, but the amounts do not. In a Nykaa Fashion workflow, this often points to deductions, returns, fee adjustments, rounding differences, or settlement timing differences.
Unmatched
These are records present on one side but not found on the other. For example:
- Present in the ERP but not in the marketplace file
- Present in the marketplace file but not in ERP
- Present in the settlement file but not in the sales file
Skipped
Skipped records are rows that were excluded from reconciliation because of missing data, invalid amounts, duplicates, or file issues. Keeping skipped rows visible helps teams understand what was not processed and why.
Matching logic for marketplace and ERP data
Cointab supports structured matching across a range of reconciliation patterns, including:
- one-to-one matching
- one-to-many and many-to-one matching
- many-to-many grouping
- net-to-net comparison
- partial matching
- contra-style matching where relevant
This matters for marketplace reconciliation because one order may be split across fees, returns, or multiple settlement lines. The system is built to compare records based on identifiers, amount logic, and reference fields instead of relying only on spreadsheet formulas.
Supporting data and derived columns
Marketplace reconciliation often needs more than the primary reports. Cointab allows teams to upload supporting data for enrichment or lookup, such as mapping files, product masters, or tax-related reference data.
Users can also create derived columns when a clean comparison field is needed. For example, a team may want to:
- clean an order ID
- normalize a transaction reference
- calculate net amount after fee
- create a delivered payment amount
- combine multiple reference fields into one match key
AI can help generate Excel-style formulas for these derived columns, which reduces manual formula building while keeping the workflow reviewable.
Handling open items and exceptions
Not every item should be forced into a match. After structured matching is complete, Cointab can analyze remaining open transactions to help teams understand possible reasons for the difference.
This is useful when the issue may involve:
- a missing file
- a delayed settlement
- a return or refund
- a fee or deduction
- a partial reference mismatch
- inconsistent partner data
If the evidence is not strong enough, the item can remain unmatched. That keeps the reconciliation audit-friendly and avoids weak assumptions.
Manual match for business-approved exceptions
Some cases need human review. If a finance user knows the business context and the amounts tally, they can manually match records that the system did not close automatically.
Manual matches remain visible in the report history, which helps teams keep an audit trail of exception handling and review decisions.
Reconciliation reuse for recurring periods
A major advantage of Cointab is that the Nykaa Fashion marketplace reconciliation setup can be reused for future periods. Once the workflow is configured, finance teams typically only need to:
- Select the reconciliation.
- Choose the period.
- Upload the required files or use automated inputs.
- Run reconciliation.
- Review the report and exceptions.
This reduces repeat setup work and helps teams maintain consistency across month-end or settlement cycles.
Reporting and audit readiness
Once the reconciliation is complete, users can review a report dashboard with summaries and transaction-level detail. The report can include matched, partially matched, unmatched, and skipped records, along with filters for deeper analysis.
Teams can also download an Excel report for internal review, partner follow-up, and audit support. Because the results are structured and reviewable, the reconciliation is easier to share across finance, accounting, and marketplace operations teams.
For finance teams managing marketplace operations
This use case is especially relevant for teams that need to reconcile:
- marketplace sales against ERP
- marketplace settlements against books
- payouts against bank receipts
- returns and deductions against accounting entries
- order-level records against summary settlement files
Cointab gives these teams a reusable workflow instead of a one-off spreadsheet process, so reconciliation can become part of regular finance operations rather than a manual month-end scramble.