ERP vs Quick-Commerce O2C: System of Record vs Commercial Event Layer

Why "It's Already in the ERP" Is Half True

The finance team is right about one thing: the invoice and the payment do end up in the ERP, and they should. What the ERP never sees is everything that happened before those two entries — and in quick commerce, "everything before" is where the money leaks.

Consider what a single Blinkit PO generates on its way to cash: a PO document with the platform's own SKU codes and a specific buyer GSTIN; an approval decision where operations cuts three SKUs to crate multiples and records reasons; a picklist allocated by batch and expiry; an appointment slot with a hard delivery window; a GRN where the dark store accepts less than what was shipped; and weeks later, a settlement file whose deductions need to become credit notes that actually match the shortfall. None of these are accounting entries. All of them determine what the accounting entries should say.

ERP has no native object for a platform PO version, a SKU-level cut reason, an appointment gate or a GRN variance classification. Brands that try to force these into ERP end up in one of two places: a long customization project that recreates an operations tool inside an accounting system, or — far more commonly — a ring of spreadsheets around the ERP where the commercial truth actually lives. The mistake is not owning an ERP. The mistake is expecting it to model every platform, warehouse and exception event simply because it stores the final invoice and payment entry.

A System of Record and an Event Layer Are Different Jobs

A system of record is optimized for finality: entries are posted, periods are closed, auditors rely on it. A commercial event layer is optimized for the opposite — flux. POs get revised, quantities get cut, GRNs disagree with invoices, deductions arrive with cryptic codes. The event layer's job is to capture each of these events with its source document preserved, resolve the differences while they are still resolvable, and hand the ERP a transaction that is already clean and classified.

That ordering matters. When raw channel noise posts straight into ERP, every mismatch becomes a finance problem discovered at month-end, stripped of its operational context. When the event layer resolves upstream, the ERP receives fewer, better entries — and each one carries a trail that explains itself: this invoice is short of the PO because these SKUs were cut for this reason; this credit note exists because this settlement file recorded this deduction.

The design goal is emphatically not two systems of record fighting over the same objects. It is a clear division of responsibility — each object owned once, in the layer built for it. For the full walkthrough of the workflow the event layer runs — capture, approve, fulfill, invoice, GRN, settle, feed ERP — see our quick-commerce order-to-cash guide.

Who Owns What: The Object-by-Object Split

The cleanest way to draw the boundary is per object, not per department. Here is the ownership map we recommend — and run in production:

Three rows deserve a note. The WMS row is flexible in one honest way: FilFlo works alongside an existing WMS or 3PL — exchanging order and status events with it — or runs picking, scanning and dispatch itself for brands that don't have one. Either way, physical execution status has exactly one authority.

The invoice/IRN row is deliberately "configured, not fixed." Some architectures have the O2C layer generate the GST invoice and IRN — FilFlo does this natively, with e-way bills, multi-GSTIN invoicing profiles and per-profile invoice series — while others keep invoice creation in the ERP or a tax engine, with the O2C layer linking references into the order trail. What matters is deciding the source once, so two systems never mint competing documents.

And the bank receipt row stays with ERP and the bank — cash is theirs. What the O2C layer contributes is the explanatory trail: FilFlo closes the GRN gap and manages credit notes against platform settlement files today, so the receipt that lands in ERP already has matched documents behind it. Full deduction classification and payment reconciliation are on the roadmap.

The Reference Architecture: Live With Microsoft Dynamics 365

This division of responsibility is not a whiteboard diagram — it runs in production. FilFlo's Dynamics 365 Finance & Operations integration is a live, bidirectional native API connection (OData), and it is the reference architecture for what the ERP boundary should look like.

If your ERP is SAP or Oracle rather than D365, the pattern still holds — those are scoped implementations through your architecture rather than a ready connector, and the D365 integration is the working proof of what the boundary looks like when it's done.

No API? File-Based ERPs Follow the Same Split

Not every accounting system needs — or offers — an API connection, and the division of responsibility doesn't depend on one. For Tally, FilFlo maintains dedicated field mappings — Tally Customer Name and Tally Item Name against each customer and SKU — that flow into report exports formatted for Tally import, so the books receive entries under the names Tally already knows. For Zoho Books, invoice and credit-note exports come out in Zoho's import format, including tax-name mapping configured per customer.

These are file workflows, and we label them as exactly that — no connector claims. The architectural point survives the transport: the O2C layer resolves the commercial events, and whatever reaches the accounting system — over an API or in an import file — is already clean, classified and explainable.

How to Draw the Line in Your Own Stack

If you take one thing from this post, make it the discipline of assigning each object one owner. In practice that means four decisions:

Get these four right and the "ERP vs O2C" debate dissolves. The ERP does what it has always done best — authoritative books, statutory compliance, cash — and the event layer does what ERP was never asked to do: keep the commercial middle of quick commerce clean enough that the books stay believable.

Frequently Asked Questions