Running a 100-outlet purchase cycle from GRN to bank payment on ERPNext

Living Liquidz is a premium liquor retail chain in Mumbai with more than 100 outlets and 400 to 500 brands on its shelves. When we started, it was processing more than 1,000 supplier bills a day. After the work described here, its capacity rose to 1,500 to 2,000 invoices a day.

This piece is about how that purchase cycle runs on ERPNext, from the goods receipt at a store to the bank payment to the supplier, and about the one design decision we would repeat for any multi-outlet retailer: treat the supplier's payout statement as the product.

What was going wrong

The company ran on a legacy .NET system. Invoice entries were made in registers. Paper bills moved physically between teams. Payments went out by cheque.

At a few hundred bills a month, that can work. At more than a thousand a day, any paper process fails in the same predictable ways:

• Nobody can see where a bill is. The only way to find out is to ask, and the answer depends on who you ask.
• Errors are found late. A wrong quantity on a bill is caught at finance, days after the goods were received, when the person who received them has moved on to other deliveries.
• Every delay becomes an argument between departments, because there is no record of who held the bill and for how long.
• Suppliers chase payments by phone, and each call pulls someone off the queue.

None of this is a software feature problem. It is a problem of a physical object, the bill, being the workflow.

Start at the goods receipt, not the invoice

The first decision was where the cycle begins. In many purchase systems the invoice is the starting point: a bill arrives and someone keys it in. In a retail chain that starts too late. The goods have already arrived at an outlet, and that receipt is the fact everything else must match.

So the cycle starts with the GRN. Goods receipts from the legacy store system are synced into ERPNext on a schedule. When a supplier's bill arrives, it is attached to a receipt that already exists, rather than creating a new record that someone later has to match.

Store staff are not ERP users, and should not have to become ones. We built a store mobile app for them, and kept it narrow:

• Pick the GRN, then scan the supplier's bill; the app converts the image to PDF and uploads it against that GRN.
• See the status of every document uploaded from that outlet.
• Filter by date and status.
• See invoice details, gross against net.

That is all. The store's job is to get the document into the system against the right receipt, the day it arrives. Everything after that is someone else's job, and the app shows them where it went.

One record per store, one queue for the company

In ERPNext each outlet's purchase runs through the standard documents: Purchase Receipt, Purchase Invoice and Payment Entry, per store. That keeps stock, liabilities and payments attributable to the outlet without building anything custom for the accounting.

On top of those documents sits a role-based approval workflow with seven stages:

1. GRN sync from the legacy system
2. Document upload from the store app
3. IT verification
4. Purchase validation
5. Finance verification
6. Director approval
7. Payment processing

Each stage belongs to a role, and each person sees only the queue that is theirs. At every stage the same small set of actions is available: approve, reject, hold or update. A management dashboard shows every invoice stage across departments, including GRN and document status, claims and settlement, finance approval, and payment requisition and approval, so a bottleneck is visible the day it forms rather than when a supplier complains.

Two things made this workable at volume.

Supplier-wise filtering and bulk approval. An approver does not open a thousand documents one at a time. They filter by supplier, review the GRN-level and invoice-level detail, and approve a batch. The control is in the review, not in the number of clicks.

An activity log on every transaction. Every action is recorded against a person and a time. This is what ended the blame between departments. When the record shows where a bill waited and for how long, the argument stops being about who is at fault and starts being about why that stage is slow.

From approval to bank

Cheque signing was the slowest step in the old process, and the easiest to fix. Approved invoices now go into bulk payment runs, through a payment gateway or bank payment files. Payment processing is priority-based, so that the business decides which suppliers are paid first rather than whichever cheque happened to be signed first.

We also built a discount and scheme automation engine. Retail purchase terms are rarely just a rate: there are schemes, discounts and claims, and they have to be reflected in what the supplier is actually paid.

Accounting stays in Tally, integrated with ERPNext. We did not move the books; we moved the workflow that feeds them.

The payout statement is the product

Here is the part most purchase projects underweight.

A supplier selling 400 brands into 100 outlets does not receive one payment per invoice. They receive one bank credit that settles many invoices across many stores, net of discounts, schemes, claims and deductions. If they cannot tell from your statement which invoices that credit covers, and why the amount differs from what they billed, they will call. Multiply that by every supplier and every payment run, and the phone becomes your largest hidden cost of processing.

So we treated the vendor payout statement as a deliverable in its own right. The one we built has 22 columns. The exact columns matter less than the principle behind them: the statement has to answer, line by line, every question a supplier's accountant will ask when they try to match your payment to their ledger. In general terms that means:

• which invoice, from which outlet, against which goods receipt;
• what was billed, gross;
• what was deducted, and under which scheme, discount or claim;
• what was paid, net, and in which payment.

Design it with the supplier's reconciliation in front of you, not your own month-end. If a supplier can match the payment without calling you, the statement is doing its job.

A vendor portal API, with limits

Some suppliers want to pull this data into their own systems rather than read a statement. We gave them a vendor portal API with two deliberate constraints: a 90-day window and a rate limit.

The window keeps each query bounded. A supplier asking for "everything" across years of invoices from 100 outlets is a heavy query; a supplier asking for the last 90 days is a routine one. The rate limit protects the ERP from a supplier's integration that polls every few seconds during the hours your approvers are working. An open API without limits invites exactly that. Both constraints are easy to explain to suppliers, and they protect the people working in the system.

What changed

The system runs on ERPNext, hosted on Frappe Cloud.

What we would tell a retailer starting this

• Begin at the receipt. The GRN is the fact; the invoice is a claim against it.
• Give stores one job. A narrow app that uploads documents against receipts beats a full ERP login nobody uses.
• Give every stage an owner and a log. Accountability comes from the record, not from a meeting.
• Approve in bulk, review in detail. Filter by supplier, look at the exceptions, approve the rest.
• Write the payout statement for the supplier. Every call it prevents is time back in the queue.
• Put limits on any API you open. A bounded window and a rate limit are cheaper than an outage.

If this is your situation

If your outlets still send bills by hand, or your suppliers still ring to ask what a payment covers, read the Living Liquidz case study and our retail and distribution page, or see how we approach an ERPNext implementation. Then tell us how many outlets and bills a day you handle.