Before there's a screen for any of this, there's a real business moving real stock. Here's what actually happens, stage by stage, and which part of TreadChain handles it.
Where every unit of stock in the system starts — a real delivery, checked before it's trusted.
A supplier's truck shows up with an invoice — a paper bill, a scan, or a photo taken on a phone. There's also a manual-entry path for the times there's no document to scan at all, like a phone order confirmed verbally.
An AI-assisted extraction step reads the scanned invoice and pre-fills a review form — supplier, invoice number, line items, quantities, rates, and tax. It's a staging area, not a direct write to stock, because extraction can occasionally misread a digit on financial data.
Someone checks the pre-filled form against the actual delivery, fixing anything that looks wrong, matching each line to an existing product (or creating a new one), and deciding whether each line goes to the central warehouse or straight to a specific dealer.
Once reviewed, the invoice is applied — one stock movement per line, posted to the warehouse or the target dealer's own ledger. This is the moment stock actually becomes real in the system, and the moment the product's cost basis for profit reporting is updated.
Behind the scenes: every one of these steps — the extracted line items, who reviewed them, and the exact stock movement each line produced — is a permanent record in TreadChain. See Features for how the traceability holds together.
Stock cascades tier by tier — warehouse to distributor, distributor to wholesaler, and on down — never skipping a level silently.
A wholesaler running low on a product requests a transfer from its parent distributor — or from another dealer if the network allows lateral transfers. The source can be the central warehouse or another dealer's own stock.
A requester can never approve their own request — a deliberate maker-checker control. Once approved, the source's stock is earmarked so it can't be double-promised to two transfers at once.
The stock physically leaves the source. This is the moment the source's on-hand quantity actually drops — not at request, not at approval.
Only once the receiving dealer confirms does its own stock ledger go up. If something doesn't arrive, the transfer can be rejected or cancelled instead — nothing is assumed.
Worked example: a retailer requests 40 units from its parent wholesaler. The wholesaler's stock manager (not the retailer) approves it, dispatches it the same afternoon, and the retailer confirms receipt the next morning — at which point, and only then, the retailer's own stock count goes up by 40 and the wholesaler's drops by 40.
A dealer sells out of its own stock, never the central warehouse directly — and never oversells past what it actually holds.
A dealer places an order for its own customer, listing what they're buying. Nothing is deducted yet — placing an order is a request, not a commitment.
Confirming checks the order against the dealer's real, current stock — a fail-fast check that catches an obvious shortfall before the customer is told "yes."
Fulfilling is the real, authoritative stock deduction — the dealer's ledger drops the moment goods actually leave, with a fresh availability check that would block the fulfilment outright if the stock genuinely isn't there.
Once fulfilled, a GST invoice generates straight from the order — dealer, customer, and every line item carried across automatically. A quick walk-in sale can skip the order entirely and go straight to a standalone invoice instead.
A note on off-books sales: not every sale needs a formal invoice right away. Rather than leaving that ambiguous, an order can be explicitly flagged as not requiring one — so a report can always tell "invoice not yet issued" apart from "deliberately not required."
Cash sales settle on the spot. Credit sales are tracked until they're not owed anymore — automatically, not from memory.
Cash, UPI, card, cheque, and bank-transfer invoices are marked fully paid the instant they're issued — settled on the spot, no further step needed. A credit invoice starts unpaid, with a due date set from your tenant's default credit period.
A customer can pay all at once or in parts — every payment is recorded against the invoice, and the outstanding balance updates immediately. Nothing is ever assumed paid.
A tenant-wide aging report buckets every outstanding invoice by how many days past due it is. A provisional credit score per customer — built from overdue count, average days late, and outstanding-versus-limit ratio — is shown with the exact reasoning behind it, not presented as a black box.
Once an invoice is overdue, a reminder email goes out automatically, once a day, until it's settled. Staff can also log a phone call or a visit directly against the customer, so the next person who checks knows what's already been discussed.
Worked example: invoice OUT-001000 is issued on credit for ₹37,760 with a 60-day due date. A part-payment of ₹10,000 comes in three weeks later, dropping the balance to ₹27,760 and the status to Partially Paid. If the due date passes with a balance still outstanding, the status becomes Overdue and the daily reminder email begins.
Bring your current stock sheet — we'll show you exactly how it maps.
Request a Demo