Quick Commerce Order-to-Cash: The Complete Guide for Indian CPG Brands
Quick-commerce revenue is governed by dozens of operational events between the purchase order and the payment — and no conventional system owns all of them. This guide defines the quick commerce order to cash process end to end: the eight stages, the event model, the metrics that matter, a reference architecture, and a buying checklist for evaluating software.
Quick Answer
Quick Commerce Order-to-Cash (QC-O2C) is the operating process that manages every revenue-governing event between receiving a quick-commerce purchase order and reconciling the resulting payment. It covers PO intake, commercial validation, fulfillment, GST invoicing, dispatch, delivery, GRN matching, deductions, disputes, cash application and the final ERP posting.
The category exists because quick commerce is not simply another ecommerce order source. Platforms buy inventory from brands through B2B POs, often against specific GSTINs and locations, with strict fulfillment windows and downstream GRN and deduction behavior. That creates a workflow spanning operations, supply chain, warehouse, logistics and finance.
Why Conventional Systems Leave a Gap
ERP is the accounting system of record. A WMS runs the physical warehouse. An ecommerce OMS routes consumer parcels. A reconciliation tool often starts after invoices or settlements exist. Each is useful, but none necessarily owns the full commercial event trail for a quick-commerce PO.
The gap appears between systems. A PO may be downloaded from a portal, modified in a spreadsheet, sent to a 3PL on WhatsApp, invoiced in ERP, dispatched against a slot, received with a short GRN, deducted in a platform statement and finally paid as part of a bulk remittance. Each system holds a fragment. Nobody holds the explanation.
The Eight Stages of QC-O2C
Each stage below is a control point. Skip one and the difference it should have caught surfaces later — usually at settlement, when the evidence is hardest to reconstruct.
PO intake and normalization
The cycle begins when a platform issues a purchase order to the brand. The PO carries buyer entity, GSTIN, destination, platform SKU codes, quantities, prices, delivery dates and commercial terms. The first control is not merely importing a file; it is normalizing the order into internal customer, SKU, tax, warehouse and rate-card records while preserving the original document.
Key questions: Was the PO received completely? Is the buyer entity mapped to the right GSTIN and invoice series? Do platform SKU codes map to internal SKUs and case sizes? Does the unit price match the agreed rate? Is the destination serviceable within the slot?
Commercial and inventory validation
The brand decides what it can and should fulfill. Available stock, shelf life, batch rules, MOQ, warehouse allocation, rate cards and delivery windows determine the approved quantity. Every quantity cut should carry a reason and approver. Otherwise the business cannot distinguish demand loss from stock loss, price disputes or operational choice.
The important output is an approved commitment at SKU level: ordered, approved, rejected and reasoned quantities, tied to the original PO.
Fulfillment orchestration
The approved order becomes work for the warehouse and logistics teams. Picklists, batch/FIFO allocation, labels, packing information, appointment details, transporter data and dispatch readiness must remain tied to the commercial order. If a 3PL or WMS executes the floor, QC-O2C should exchange order and status events rather than recreate warehouse logic.
The control objective is simple: surface exceptions early enough to act. A missing batch, unmapped SKU, unavailable slot or delayed truck should not become a surprise after the PO expires.
GST invoicing and e-way bill
The invoice must reflect the correct seller GSTIN, buyer GSTIN, supply and dispatch context, HSN, tax rate, quantity, price and invoice series. For businesses covered by Indian e-invoicing rules, the IRN and signed QR code are part of the flow. When an e-way bill is required, it should be generated with the dispatch details and remain linked to the order and invoice.
QC-O2C does not replace tax advice or statutory systems. Its job is to make the operational inputs consistent and preserve the evidence that produced the invoice.
Dispatch, delivery and proof
The system records when and how goods left the warehouse, the transporter or vehicle reference, the appointment, delivery confirmation and proof. This is the bridge between invoice and GRN. Without it, finance sees a short payment later but cannot reconstruct whether the underlying problem was short dispatch, transit damage, missed appointment or receiving variance.
GRN matching
The goods receipt note is where the platform records what it accepted. Compare ordered, approved, invoiced, dispatched, delivered and received quantities at SKU level. A difference should become a typed exception — short received, damaged, rejected, wrong item, excess or timing mismatch — with supporting documents and an owner.
GRN is not a warehouse afterthought. It is one of the strongest predictors of what will be paid.
Deductions and disputes
Platform payments may include deductions for shortages, damages, commercial schemes, service levels, pricing differences, returns, taxes or other adjustments. A defensible process classifies each deduction, links it to the relevant PO, invoice and GRN, assigns evidence and records whether it is accepted, disputed, recovered or written off.
The objective is not to dispute everything. It is to know which deductions are valid, which are preventable and which can be recovered with evidence before the dispute window closes.
Payment reconciliation and ERP posting
The final stage matches bank receipts and remittance information to invoices and adjustments. Finance should be able to explain the remaining difference and its status. Clean, classified results then feed ERP: payment applied, deduction posted, dispute receivable created, credit note issued or write-off approved.
The cycle is complete only when cash and exceptions are both accounted for. “Invoice generated” is not the end of order-to-cash.
Stages seven and eight describe the category process every brand needs to run, whatever tools it uses. On FilFlo's side: FilFlo closes the GRN gap and manages credit notes against platform settlements today; deduction classification and payment reconciliation are on the roadmap. Settlement and PRN files from platforms like Blinkit can be imported to generate matched credit notes in bulk.
The QC-O2C Event Model
A useful system represents events rather than only statuses. A status says "Delivered." An event trail explains who marked it delivered, when, with which proof, what quantity the platform received, what mismatch followed and what action was taken.
PO received, file version, portal acknowledgment, customer/GSTIN mapping, SKU mapping.
Quantity approved, quantity cut, reason, approver, warehouse allocation, price exception.
Picklist created, batch allocated, invoice generated, IRN generated, e-way bill generated, dispatch recorded, delivery confirmed.
GRN received, mismatch classified, deduction detected, dispute raised, evidence submitted, dispute resolved.
Remittance received, bank receipt matched, shortfall classified, credit note issued, write-off approved, ERP posted.
How QC-O2C Differs From Adjacent Categories
QC-O2C is not a replacement for the systems a brand already runs. It is the layer that owns the commercial event trail those systems each see only a fragment of.
| System | Primary job | Typical gap for QC-O2C |
|---|---|---|
| ERP | Accounting, ledgers, statutory and enterprise master data | Often sees final transactions but not every portal, warehouse and dispute event. |
| WMS | Put-away, bins, picking, packing and warehouse-floor execution | Does not own buyer PO economics, GRN deductions or payment reconciliation. |
| B2C OMS | Marketplace parcel routing, courier booking, returns and NDR | Consumer-parcel logic differs from B2B POs, GSTIN series and GRNs. |
| Demand planning | Forecast demand and recommend inventory | Does not execute or reconcile the order-to-cash cycle. |
| Reconciliation tool | Match invoices, settlements and payments | May begin after the upstream PO and fulfillment events that caused the difference. |
| QC-O2C | Own the event trail from platform PO to reconciled cash | Should integrate with — not duplicate — the systems above. |
Metrics That Matter
Every metric below should be measured from your own event trail with a stated definition — a fill rate without a stated denominator is a debate, not a metric.
PO capture completeness
Percentage of platform POs captured with no manual rekeying or missing lines.
PO acknowledgment time
Time from PO availability to validated internal order.
Approval loss rate
Ordered quantity minus approved quantity, classified by reason.
Fill rate
Accepted quantity divided by ordered or approved quantity — define the denominator and keep it consistent.
On-time-in-full (OTIF)
Orders delivered within the committed window and accepted in full.
Invoice accuracy
Invoices without price, tax, entity, quantity or reference errors.
GRN variance rate
Quantity or value variance between invoice/delivery and platform receipt.
Deduction rate
Deductions as a percentage of invoiced value, by category and platform.
Dispute recovery rate
Disputed value recovered divided by eligible disputed value.
Unexplained cash gap
Received cash difference that lacks a classified reason.
PO-to-cash cycle time
Elapsed time from PO receipt to reconciled payment.
Exception ageing
Open exceptions by type, owner and days outstanding.
Reference Architecture
A sound architecture keeps systems in their lanes. Platform portals and feeds remain external sources. The QC-O2C layer captures and normalizes commercial events; ERP remains the accounting system of record; WMS/3PL systems execute the floor; tax and banking systems provide statutory and cash events. The integration boundary should be explicit for every object: who creates it, who can modify it, which system is authoritative and how disagreements are resolved.
The minimum object set is customer and GSTIN, location, SKU and channel SKU mapping, rate card, PO, approval decision, pick/dispatch reference, invoice and IRN, e-way bill, proof of delivery, GRN, deduction, dispute, remittance, bank receipt and ERP posting reference.
For a worked example of an explicit boundary, see how FilFlo connects to Microsoft Dynamics 365: approved orders are pushed into ERP and invoices are read back, so the ERP stays the system of record while the O2C layer owns the events in between. System-to-system access in the other direction runs through a public API and order webhooks.
What Good Implementation Looks Like
Start with one platform, one warehouse, one GSTIN and a representative set of ugly orders.
Map every event, source, owner, control and exception before automating.
Clean customer, SKU, tax, rate-card and location mappings.
Run parallel operations until the team can explain every difference between the new event trail and existing records.
Automate repetitive actions only after decision rules and fallback ownership are clear.
Measure a baseline before go-live; publish results only after a defined post-implementation window.
Expand platform, entity and warehouse coverage using the same taxonomy rather than creating new spreadsheets per channel.
Want to See the Stages Run on a Real PO?
Bring a real Blinkit, Zepto, Instamart, modern-trade or distributor PO to a working session. Map every event from intake to payment and identify where revenue, time and evidence disappear.
Buying Checklist
Ten questions to put to any vendor — including FilFlo — before you commit. The answers should be specific to your PO formats, your entities and your warehouses.
- Can the vendor ingest your real PO formats and preserve the source document?
- Does it model GSTIN, invoice series, channel SKU and rate-card differences?
- Can every quantity change be reasoned and approved?
- Does it integrate with the WMS/3PL without pretending to replace floor execution?
- Can it connect invoice, delivery, GRN, deduction, dispute and payment at line level?
- What is automated, what is imported and what remains manual?
- What happens when the portal, warehouse and ERP disagree?
- Can you export the event trail and supporting evidence for audit?
- Which metrics are measured from your data, and how are they defined?
- Who is it not for?
Where FilFlo Fits
FilFlo is the order-to-cash operations layer for CPG brands selling through quick commerce — and other PO-driven channels such as modern trade, general trade distributors, e-commerce marketplaces, D2C and institutional sales. It captures purchase orders, SKU-level approvals, fulfillment events, GST invoices and GRNs in one reconciliation-ready event trail — and closes the settlement gap by turning platform settlement files into matched credit notes — for operations, finance and planning teams. See the product overview and the full feature list for the capability detail behind each stage.
ERP remains the accounting system of record: FilFlo pushes approved orders into ERP and reads invoices back — live today with Microsoft Dynamics 365. On the platform side, POs arrive through workflows like the Blinkit webhook workflow and Zepto PO ingestion with ASN submission, and a public API with order webhooks connects customers and partner systems.
On warehouse execution, FilFlo works alongside an existing WMS or 3PL — or runs picking, scanning and dispatch itself for brands that don't have one, including barcode-scanner-based picking and dispatch scanning on the warehouse floor. On the finance tail, FilFlo closes the GRN gap and manages credit notes against platform settlements today; deduction classification and payment reconciliation are on the roadmap. AI agents help fetch, classify, reconcile and route routine work — and recommend replenishment before stockouts happen — while teams remain responsible for approvals and exceptions.
FilFlo is not the right tool when the only problem is consumer-parcel courier routing, a standalone bulk IRN utility, or global factory planning. In those cases, a specialized B2C OMS, compliance tool or enterprise planning suite is a better fit.
Operator Glossary
The terms operations and finance teams use daily in quick-commerce order-to-cash work.
Appointment
The delivery slot a platform assigns for a PO. Goods must arrive within the slot; a missed appointment usually means rebooking, and often PO expiry.
ASN
Advance Shipping Notice: dispatch information sent before goods arrive. Zepto, for example, reconciles a submitted ASN against its own PO line by line — see how FilFlo submits Zepto ASNs.
CFA
Carrying & forwarding agent: a third-party stocking and dispatch point. Documents often need per-site (per-CFA) item codes rather than one code per SKU.
Crate MOQ
A rule that floors order quantities to full crates: approved quantities are rounded to crate multiples rather than approved as loose units.
Deduction
An amount withheld or adjusted by a buyer against invoice value.
Dispute
A formal challenge to a deduction, mismatch or short payment, supported by evidence.
E-invoice / IRN
An invoice registered through India's invoice registration system, producing an Invoice Reference Number and signed QR code where applicable.
E-way bill
The statutory movement document required for qualifying goods transport in India.
Fill rate
Accepted or fulfilled quantity divided by a defined ordered or approved quantity. The denominator must be stated.
GRN
Goods Receipt Note: the buyer's record of goods received and accepted.
GSTIN
Goods and Services Tax Identification Number for a registered entity/location context.
MOQ
Minimum Order Quantity: the smallest quantity allowed for a product or order rule.
O2C / OTC
Order-to-cash: the business cycle from accepted order through fulfilled, invoiced and reconciled payment.
OMS
Order Management System. In ecommerce it often centers on consumer parcels; in B2B it centers on purchase orders.
OTIF
On Time In Full: an order delivered within the committed time and accepted at the required quantity.
PO
Purchase Order issued by a buyer to a brand or supplier.
POD
Proof of Delivery: evidence that a shipment was delivered.
PRN
Platform return/settlement note: the platform document recording returns and settlement adjustments — the raw input for creating matched credit notes.
Rate card
The agreed price or commercial terms for a customer, channel, location or SKU.
Reconciliation
Matching records from different systems and explaining every difference.
Short ship
A shipment containing less than the approved or invoiced quantity.
System of action
A workflow system that recommends or executes next steps rather than only storing final records.
WMS
Warehouse Management System for physical warehouse processes such as put-away, picking and packing.
Working capital
Cash tied in operating assets such as inventory and receivables, net of operating liabilities.
Bring a Real PO and Its Payment Statement
FilFlo will map the missing events between them — intake, approval, fulfillment, invoice, GRN and credit notes — on your own data, in a 30-minute working session.