Blinkit PO to Payment: The Order-to-Cash Cycle for Brands (2026)
Blinkit's order-to-cash cycle runs in ten steps: Blinkit raises a PO against your entity and a receiving location; you check it against its expiry date; you approve quantities with reasoned cuts; you raise a GST invoice with IRN; you generate an e-way bill where the movement needs one; you deliver inside a booked appointment; Blinkit records a GRN of what it accepted; you classify short, excess and damaged units; you match credit notes to Blinkit's settlement file; and payment lands on the terms in your vendor agreement.
The PO is the commercial anchor, but the GRN decides what you are paid for. Almost every rupee that goes missing between invoice and cash goes missing in a step where the trail broke. This guide walks each step, shows the controls that matter, and is honest about what varies by contract.
Key Takeaways
- Plan every Blinkit PO backwards from its expiry date and the next available appointment, not forwards from the day it arrived.
- Every quantity cut needs a reason and an approver, or you cannot separate demand loss from stock loss later.
- The GRN, not the invoice, decides what gets paid. Capture it against the same order and type every variance.
- Settlement adjustments arrive as files. Matching one credit note per invoice is the difference between a closed month and a spreadsheet war.
- Payment terms, margins and fees vary by commercial model and contract. Read your vendor agreement; ignore numbers quoted on blogs, including this one.
The Cycle at a Glance
| Stage | Document | Owner | Control that matters | What breaks |
|---|---|---|---|---|
| PO intake | Purchase order | Blinkit | Item, entity and location mapping | Unmapped item codes, wrong GSTIN |
| Validity | PO expiry date | Brand | Plan backwards from expiry | PO lapses before delivery |
| Approval | Approved quantities | Brand | SKU-level cuts with reasons | Unexplained fill-rate loss |
| Invoice | GST invoice with IRN | Brand | Right GSTIN, series and PO rate | Rate or entity mismatch |
| Movement | E-way bill | Brand / transporter | Validity vs appointment date | Expired e-way bill in transit |
| Delivery | Appointment slot | Brand books, Blinkit receives | Arrive inside the window | Missed slot, rebooking |
| Receipt | GRN | Blinkit | Capture against the order | Short payment you cannot explain |
| Variance | Typed mismatch | Brand | Reason per SKU line | Disputes without evidence |
| Adjustments | Credit notes vs PRN | Brand | One credit note per invoice | Manual keying errors |
| Cash | Payment | Blinkit | Every difference explained | Unexplained cash gap |
Step by Step: From Blinkit PO to Payment
PO intake
Blinkit raises a purchase order against your entity: header, lines, buyer details and the receiving location, in Blinkit's own item codes, with a price on each line. The first control is not importing the PO, it is normalising it: Blinkit item codes mapped to your SKUs and case sizes, the buyer entity mapped to the right GSTIN and invoice series, and the receiving location mapped to the warehouse that will serve it. Keep the source document; you will need it when the GRN disagrees with you.
Validity check
Every PO carries an issue date and an expiry date. Work backwards from the expiry: is there stock with enough shelf life, can it be picked and invoiced in time, and is there an appointment slot before the PO lapses? A PO that cannot be met inside its window should be cut or flagged now, not discovered at the gate.
Approval with cuts
Approve quantities at SKU level against available stock, shelf-life rules and case or crate multiples. Every cut needs a reason (no stock, short shelf life, MOQ rounding, price dispute) and an approver. Without reasons, finance cannot later tell demand loss from stock loss, and fill-rate conversations with the category team become guesswork.
GST invoice with IRN
Raise the invoice from the GSTIN the PO demands, on that GSTIN's series, at the PO rate. If you are covered by e-invoicing, the invoice is registered on an Invoice Registration Portal and comes back with an IRN and signed QR code. If stock ships from a warehouse in another state, the bill-from and ship-from details must be right on both the invoice and the e-way bill.
E-way bill
Where the movement needs one, generate the e-way bill from the same invoice data, with the transporter and vehicle details. Its validity depends on distance, so an appointment that slips by a day can leave you with an expired e-way bill and a truck that cannot move legally until it is extended.
Appointment and delivery
Blinkit receives against booked delivery windows. The vehicle should arrive inside the slot with the PO reference, invoice and e-way bill. A missed appointment usually means rebooking, and if the next slot falls after the PO expiry, the order is lost. Track appointment status per PO, not per truck.
GRN
After receiving checks (barcodes, MRP, shelf life, counts), Blinkit records a goods receipt note: what it actually accepted. The GRN, not your invoice, is what drives fill rate and what gets paid. Capture it against the same order so ordered, approved, invoiced and received quantities sit side by side.
Short, excess and damage
Compare invoice and GRN at SKU level and type every difference: short received, damaged, rejected, wrong item, excess, or timing. Short and damaged units reduce what is payable. Excess over the PO line is not something to assume will be accepted or paid; how it is handled depends on Blinkit's receiving practice and your agreement.
Credit notes against settlement
Blinkit's settlement (PRN) file, exported from the seller portal, records the returns and adjustments against your invoices. Each adjustment needs a matching credit note against the right invoice. Doing this by hand, line by line, is where most quick-commerce finance teams lose days and accuracy.
Settlement and payment
Payment follows your commercial model and the terms in your vendor agreement; there is no single public number. The cycle is complete only when every rupee between invoiced value and cash received is explained by a GRN variance, a credit note or an open dispute.
The Compliance Pieces, Briefly
E-invoicing. Since 1 August 2023, businesses whose aggregate turnover exceeded Rs 5 crore in any financial year from 2017-18 must generate e-invoices for B2B supplies (Notification No. 10/2023, Central Tax). NIC's e-invoice system applies IRNs to invoices, debit notes and credit notes for B2B and export transactions, which matters for the credit-note tail of the Blinkit cycle, not just the invoice.
E-way bills. Rule 138 of the CGST Rules generally requires an e-way bill for movement of goods above Rs 50,000 in consignment value, with validity that depends on distance. NIC's e-way bill system is at ewaybillgst.gov.in. If your vehicle changes or the appointment slips, update Part B or extend validity before the bill lapses.
GSTIN discipline. Blinkit POs are raised against a specific buyer entity and location. If you serve that location from a warehouse in another state, read our guide to bill-from and ship-from invoicing. All of this is operational guidance, not tax advice; confirm your position with your tax advisor.
Common Mistakes Between Blinkit PO and Cash
Approving against yesterday's stock
Approvals made against stale inventory turn into cuts after invoicing, which is the most expensive place to cut. Approve against live stock with shelf life applied.
Waiting on the appointment until the PO is nearly expired
If the first available slot is after the PO expiry, the PO is effectively lost. Check slot availability during approval, not after picking.
Invoicing from the wrong GSTIN or at the wrong rate
A rate that differs from the PO or an invoice from the wrong entity creates a mismatch that surfaces as a deduction weeks later.
Letting the e-way bill expire in a queue
Vehicles that wait at the gate or get rescheduled can outlive the e-way bill. Watch validity against the appointment date.
Not capturing the GRN against the order
If the GRN lives only on the portal, finance sees a short payment with no way to tie it back to a short receipt, a damaged case or a missed slot.
Keying credit notes by hand from the settlement file
Line-by-line entry from PRN files invites mismatched invoice references and duplicate or missing credit notes.
Changing the fill-rate denominator
Fill rate against ordered quantity and fill rate against approved quantity tell different stories. Pick one definition and keep it.
See One Blinkit PO Run to Credit Note
Bring a real Blinkit PO and its settlement file. We will show the PO arriving, the cuts, the IRN invoice, the GRN variance and the credit notes on one trail.
Where FilFlo Fits in the Blinkit Cycle
FilFlo is the order-to-cash operations layer for FMCG brands selling through quick commerce. For Blinkit it runs as a live webhook workflow via FilFlo-operated middleware: a webhook service built, run and monitored by FilFlo ingests PO events (header, lines, buyer entity, GSTIN and delivery location) as they arrive, maps Blinkit item codes to your SKUs, and drops the PO into the approval queue. File import is the fallback path. GRN data joins the same order trail. Documents going back to Blinkit go through the portal or file upload; there is no outbound API, and Blinkit does not build, maintain or endorse the middleware. Details are on the Blinkit workflow page.
Inside FilFlo, approval carries SKU-level cuts with reasons and crate-MOQ rules; picklists allocate by batch and expiry; GST invoices are raised with IRN on the right GSTIN and series, with e-way bills alongside; and a platform-PO tracker follows appointment status per PO. FilFlo works alongside an existing WMS or 3PL, or runs picking, scanning and dispatch itself for brands that don't have one.
On the finance tail, a PRN file exported from the Blinkit portal is imported and FilFlo generates credit notes in bulk, one per merchant invoice ID, matched to the invoices already on the trail. FilFlo closes the GRN gap and manages credit notes against platform settlements today; deduction classification and payment reconciliation are on the roadmap.
"We cut down our first-appointment order failure rate by 90%."
Jimmy's Cocktails
How We Wrote This Guide
The sequence and controls come from running Blinkit POs through FilFlo's live workflow, and match the eight-stage model in our quick commerce order-to-cash guide. Compliance statements cite NIC and CBIC sources. Blinkit does not publish its vendor terms, so receiving and appointment practices are described in general terms and every commercial number (payment cycle, margins, fees, penalties) is left out on purpose: they vary by commercial model and contract, and third-party figures conflict.
If you are deciding whether your ERP can carry this cycle on its own, our ERP vs quick-commerce O2C comparison covers where the boundary usually sits.
Frequently Asked Questions
What is the Blinkit PO to payment cycle?
It is the order-to-cash cycle for a brand supplying Blinkit: Blinkit raises a purchase order against your entity and a receiving location; you validate and approve it, with reasoned quantity cuts, before it expires; you raise a GST invoice (with IRN where e-invoicing applies) and an e-way bill where required; you deliver inside a booked appointment; Blinkit records a GRN of what it accepted; differences such as short receipts are settled through credit notes against Blinkit's settlement files; and payment follows the terms in your vendor agreement.
How long is a Blinkit purchase order valid?
Each Blinkit PO carries its own issue date and expiry date, and validity is not a single published number. Read the expiry off the PO itself and plan stock, invoicing and the appointment slot backwards from it. A PO that expires before delivery usually means lost revenue and a fill-rate hit, not a late delivery.
What happens if Blinkit short-receives my delivery?
The GRN records fewer accepted units than you invoiced, so the amount Blinkit owes you is based on the lower number. The gap has to be closed in your books, typically with a credit note matched to the original invoice. To dispute or explain it you need the invoice, the dispatch record and the GRN on one trail, with a typed reason for the variance: short, damaged, rejected, wrong item or timing.
When does Blinkit pay brands?
Payment timing depends on your commercial model and the terms in your vendor agreement, and it is not published. Third-party guides quote very different cycles, so do not plan cash flow from a blog post. What you can control is how clean the trail is when settlement arrives: every rupee of difference should already be explained by a GRN variance or a credit note.
Do credit notes against Blinkit invoices need an IRN?
If you are covered by e-invoicing, the NIC e-invoice system expects IRNs for B2B invoices, debit notes and credit notes, so a credit note against a Blinkit invoice is generally reported the same way as the invoice. Confirm the treatment for your specific case with your tax advisor; this is operational guidance, not tax advice.
How does FilFlo connect to Blinkit?
Through a live webhook workflow via FilFlo-operated middleware. A webhook service built, run and monitored by FilFlo ingests Blinkit PO events (header, lines, buyer entity, GSTIN and delivery location) and GRN data into FilFlo, with file import as the fallback. Documents going back to Blinkit are submitted through the portal or by file upload; there is no outbound API. Blinkit does not build, maintain or endorse it.
Close the Gap Between Blinkit GRN and Cash
A 30-minute demo with your own Blinkit PO: intake, approval with cuts, IRN invoice, e-way bill, GRN variance and bulk credit notes from the PRN file.
Blinkit is a trademark of its respective owner. FilFlo is an independent product; no endorsement or affiliation is implied.