The numbers behind it · Cello World's filings, FY25 to FY26
Why this problem
The case is built on Cello World Ltd, a consumer products maker selling through more than 4,000 distributors to over 1,50,000 retailers (FY25 investor presentation), mostly on credit. In FY26 its receivables grew faster than its revenue:
₹658 Cr grown at 8.8% ≈ ₹716 Cr, against ₹750 Cr actual. An estimate, not a measured backlog; receivables also rise through credit expansion, channel mix or timing. It justifies discovery, not a diagnosis. In scope: receipts, deductions, their evidence, ownership and settlement. Out of scope: credit-limit policy, collections strategy and ERP replacement.
Current state vs target state · one ₹20,000 short payment through both processes
Current process vs future process: the same ₹20,000 short payment
Invoice ₹10,00,000, paid ₹9,80,000 with no explanation. Amounts and timings are illustrative.
31 days and 9 emails, still unexplained, versus every rupee explained and owned by 09:03 on day 0. Nothing written off.
Rule parameters · change a Finance-controlled threshold and observe the classification change
Try the rules yourself
The proposed workflow above is driven by rules Finance controls. Change one and watch the payment re-classify.
Finance's settings
Try to break the controls
Each attempt should be blocked and logged.
What the owner receives
Credit check on the next order
Rule: disputes over ₹20,000 or older than 45 days (illustrative). A flag for the credit controller, not an automatic block.
Next month: paid in full
The ₹8,000 scheme benefit is issued upfront as credit note CN-0213 and reported to the by . The distributor pays ₹10,00,000 − ₹8,000 − ₹1,000 expected TDS = ₹9,91,000. Exact match; no case opened.
Audit trail
The specification · rules, reason codes, traceability, stories, UAT, RACI
For the business reader: the rules, requirements and tests behind the prototype. Every requirement traces to a pain point or research finding and forward to a test.
| ID | Layer | Rule |
|---|
Tax rules summarised for illustration; they change. Check current rules.
| Reason code | Required evidence | Valid when |
|---|
| Pain point or research finding | Requirement | Test |
|---|---|---|
| P1 No remittance detail. Virtual accounts tag each payment to its payer automatically (open.money) | BR-1, US-1 | UAT-01 |
| TDS treated as a loss is a leading cause of reconciliation differences (invoicedataextraction.com guide) | BR-2, US-2 | UAT-02 |
| 90–95% of deduction value is typically valid; 5–10% invalid (HighRadius). Unstructured claims can over-pay 5–12% of scheme spend (Terra Insight) | BR-3, US-3 | UAT-03, UAT-05 |
| P2 Unstructured reasons; P3 unclear owner. Average dispute resolution about 41 days; 44% of companies have no resolution deadline (HighRadius; Attain Consulting 2021 survey) | US-4 | UAT-04, UAT-08 |
| P4 Weak approval trail | BR-4, BR-5, US-5 | UAT-06, UAT-07 |
| Missed credit-note windows leak GST (Terra Insight example, illustrative) | BR-6, US-6 | UAT-09 |
| P5 Late visibility; old deductions compound with new credit exposure | BR-7, US-7 | UAT-10 |
Select an ID to open its definition.
| ID | Traces to | Scenario | Expected result |
|---|
| Activity | AR exec | AR lead | Controller | Sales | IT / ERP | Audit |
|---|---|---|---|---|---|---|
| Match payments to invoices | R | A | I | C | ||
| Investigate a difference | R | A | C | |||
| Confirm a scheme or damage claim | C | R | ||||
| Approve a deduction or write-off | R | A | C | I | ||
| Post the adjustment in the ERP | R | A | C | |||
| Report exception ageing | R | A | I | I | I |
R = does the work, A = accountable, C = consulted, I = informed. The distributor is the external party in every exception.
Trade-offs, the one metric, and how I'd validate it
Trade-offs I chose
- Control before speed: ownership and approvals first, automation second.
- Strict matching at launch: fewer auto-matches, zero wrong ones.
- ERP stays the system of record: a workflow layer (proposed: a platform such as ServiceNow) posts only approved outcomes.
- No automatic write-offs: small items may wait for a person.
- Automate only the evidenced majority: needs a Finance-approved tolerance.
- Prevent before you reconcile: Sales must agree scheme budgets upfront.
How I'd measure it
One number decides it: the share of short-paid rupees with a class and an owner on the day the payment arrives. Target: all of them.
It should move one business outcome: receivables growing faster than revenue (₹658 Cr → ₹750 Cr against +8.8% revenue).
Guardrails, not goals: zero wrong write-offs; credit notes reported within 30 days.
How I'd validate it
- Five 45-minute interviews: AR executive, AR lead, Finance Controller, area sales manager, ERP owner
- One month of anonymised receipts
- Stop rule: if gaps are rare or close within days, stop and redirect to wherever finance spends the most manual effort.
Full case study (PDF)One-pager (PDF)Business requirements document (PDF)
Where this would fail · three risks and the design answer to each
Where this would fail
Distributors keep paying the old account
Virtual accounts only identify the payer if they are used. Design answer: the old account stays open for a quarter with receipts matched by the oldest-invoice rule, and Sales gets a weekly list of distributors still using it.
Scheme rules change mid-quarter
Auto-acceptance is only as good as the budget it checks. Design answer: no scheme is valid until Sales enters it with dates and a budget; claims against an unentered scheme go to a person, never through.
Sales overrides the credit flag
A flag nobody respects is noise. Design answer: the flag never blocks an order, but every override is logged with a name, and overrides per area appear in the monthly review.
How this evolved · v1 assignment → v2 research → v3 executable spec
How this evolved
- v1 · The assignment. A deduction workflow: a case with a reason code and owner, SLA routing, maker-checker, ERP as system of record.
- v2 · The research. TDS treated as a loss, 90–95% of deduction value usually valid, missed credit-note windows: answered by four layers (Identify, Split, Validate, Prevent).
- v3 · An executable specification. The page had become a long read. The rules now run as a desk: the ten UAT cases execute against it and report pass or fail, and every action is traced to its rule, story and test. The full specification sits behind one tap.