Swiggy, Urbanpiper and POS Reconciliation

Food delivery businesses often need to compare order data across Swiggy, Urbanpiper, and POS reports to confirm that every order was recorded correctly and every settlement is accounted for. When these files are checked manually in Excel, it becomes easy to miss differences in order status, amount, cancellations, fees, or payout timing.

Cointab helps finance teams automate this workflow with a structured reconciliation setup. Users upload their reports, map the required fields once, run reconciliation, and review matched, partially matched, unmatched, and skipped records in one report.

Why this reconciliation matters

Swiggy, Urbanpiper, and POS data usually represent different stages of the same restaurant order lifecycle:

• Swiggy records the customer order and delivery-side information.
• Urbanpiper often acts as the middle layer that standardizes and passes order data.
• POS records the order in the restaurant's billing or store system.

If these records do not align, finance teams may face:

• missing order entries,
• settlement differences,
• underpaid or overpaid amounts,
• cancelled orders that were still captured somewhere in the workflow,
• fee or tax mismatches,
• late adjustments that are difficult to track in spreadsheets.

A repeatable reconciliation process helps teams review these issues faster and keep an auditable record of what matched and what still needs follow-up.

Typical data sources in the workflow

Cointab uses a Side A and Side B model. For this use case, one side usually contains the restaurant's internal or source-of-truth records, while the other side contains the external platform or settlement data.

Supporting files can also be added when needed. For example, a store mapping file, fee rate file, product master, or tax mapping file can help enrich the primary data before reconciliation.

How Cointab handles the matching process

The reconciliation is set up once and then reused for future periods. A typical workflow looks like this:

1. Upload the Swiggy, Urbanpiper, and POS files.
2. Map key fields such as order ID, date, amount, and status.
3. Add supporting data if the workflow needs lookups or enrichment.
4. Create derived columns if the raw files need cleaning or calculation.
5. Run reconciliation manually or on a schedule.
6. Review the report dashboard and exception buckets.
7. Download the Excel report for internal review or audit support.

Cointab can also help generate derived columns using AI when finance teams want a calculated field without writing formulas manually. For example, a user can ask for a clean order ID, a net amount, or a normalized reference before matching starts.

What gets matched

The reconciliation engine compares records using structured logic. It can handle simple and complex scenarios, including one-to-one and grouped matching.

For this use case, common match conditions include:

• Order ID matches across Swiggy, Urbanpiper, and POS
• Amount matches after fees, taxes, or adjustments are considered
• Status matches for delivered, cancelled, or refunded orders
• Grouped records match when one source splits or combines entries differently

This is useful when one report contains a single line per order, while another breaks the same transaction into multiple lines for fees, taxes, or settlements.

How exceptions are categorized

Cointab separates the reconciliation result into clear buckets so finance teams can focus on exceptions instead of reviewing every row manually.

Fully matched

These are records where the identifier and amount match according to the reconciliation rules.

Example: a Swiggy order matches the Urbanpiper record and the POS bill with no difference in the matching fields.

Partially matched

These are records where the order appears related across systems, but the amounts do not fully match.

Example: the order ID is the same, but the settlement amount differs because of commission, rounding, tax treatment, or an adjustment.

Unmatched

These are transactions found on one side but not located on the other side.

Example: a Swiggy order exists in the external report but does not appear in POS, or a POS bill exists without a corresponding external reference.

Skipped

These are rows that were not included in reconciliation because the data was incomplete, invalid, duplicated, or outside the configured rules.

Skipped records remain visible so the team can understand what was ignored and why.

Common reconciliation scenarios

Food delivery teams often use this workflow to review situations such as:

• Swiggy orders that reached Urbanpiper and POS correctly
• orders present in Swiggy but missing in POS
• POS entries that do not appear in the platform report
• orders marked cancelled in one report but still present in another
• underpaid or overpaid settlements that need follow-up
• fee or tax differences that require clarification

When deterministic rules are not enough, Cointab can use AI to review open items, suggest possible reasons for a mismatch, and help the user decide the next action. If the evidence is not strong enough, the record remains unmatched rather than being forced into a weak match.

Manual review and exception handling

Not every exception should be auto-matched. Cointab includes a manual match option for cases where the finance or operations team knows the business context and wants to close a specific exception with reviewable control.

This is useful when:

• a reference is missing in one source,
• a file was received late,
• a cancellation or refund needs manual treatment,
• a one-off operational issue affected the data.

Manual matches remain clearly marked so the team can audit the decision later.

Reusable setup for recurring periods

This reconciliation is not limited to a one-time file upload. Once configured, the same setup can be reused for future periods such as daily, weekly, monthly, or custom settlement cycles.

That means finance teams can keep the workflow consistent instead of rebuilding formulas and file logic every time a new report arrives.

Users can also upload a missed file under the same reconciliation and refresh the report when a delayed Swiggy, Urbanpiper, or POS file becomes available.

Benefits for restaurant finance teams

A structured reconciliation workflow helps teams:

• reduce manual Excel comparisons,
• spot missing orders and payout differences faster,
• keep matched and unmatched records clearly separated,
• prepare audit-friendly reports,
• standardize the review process across outlets or periods,
• reuse the same setup across future runs,
• automate recurring reconciliation through email, SFTP, or API where needed.

For businesses handling multiple outlets or high volumes of food delivery orders, this provides a clearer view of order-level accuracy and settlement status without relying on repeated spreadsheet work.

Report outputs and audit support

After reconciliation runs, users can review the summary and transaction-level tables, filter by status, and download Excel output for internal checks or partner follow-up.

The report typically shows:

• total summary,
• fully matched transactions,
• partially matched transactions,
• unmatched transactions,
• skipped transactions,
• detailed row-level information for review.

This makes it easier for finance teams to explain differences, track open items, and maintain a clear audit trail for each reconciliation period.

Reconciliation for Swiggy, Urbanpiper, and POS data at scale

Cointab is designed for teams that want a repeatable reconciliation process rather than a one-off spreadsheet exercise. By combining structured field mapping, reusable rules, exception tracking, and audit-ready reporting, it gives finance teams a controlled way to review Swiggy, Urbanpiper, and POS records across periods and outlets.

The result is a cleaner view of what matched, what changed, and what still needs attention.