Business requirements document · Order-to-cash
Distributor deduction workflow
Cello World Ltd (case study) · Prepared by Rupak Ghanpathi
| Version | 2.0, draft for validation |
| Status | Self-initiated; built from public filings. Internal processes are hypotheses to confirm in discovery. |
| Live prototype | everyrupee-o2c.vercel.app |
1. Purpose and background
When a distributor pays less than the invoice, the gap usually mixes tax withheld, valid commercial claims and genuine disputes. Treated as one unexplained amount, it waits in email until month-end, delays cash application and hides real overdue balances while the distributor keeps ordering on credit.
Signal: in FY26 Cello's trade receivables rose 14.0% (₹658 Cr → ₹750 Cr) against revenue growth of 8.8% (₹2,136 Cr → ₹2,324 Cr), roughly ₹34 Cr above revenue pace. This is an estimate, not a measured backlog; receivables also move with credit policy, channel mix and timing. It justifies discovery, not a diagnosis.
2. Scope
In scope: distributor receipts, short payments and deductions; their identification, classification, evidence, ownership, approval and settlement as credit notes; a credit-review flag.
Out of scope: credit-limit policy, collections strategy, ERP replacement and supplier-side (procure-to-pay) matching.
3. Stakeholders
| 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.
4. Current state (hypothesised) and pain points
- P1 No remittance detail: payments can't be tied to specific invoices.
- P2 Unstructured reasons: the cause of a difference lives in emails, not in a reportable field.
- P3 Unclear ownership: Finance and Sales each assume the other is chasing.
- P4 Weak approval trail: deductions are accepted over email; audit evidence is scattered.
- P5 Late visibility: ageing exceptions surface only at month-end.
5. Assumptions and hypotheses to validate
| Hypothesis | Discovery question | How to validate |
|---|---|---|
| H1 Remittance detail is missing | "If a distributor owes ₹10 lakh and pays ₹9.8 lakh, what happens to the ₹20,000 until it's closed?" | Sample one month of bank receipts |
| H2 Ownership is unclear | "How is responsibility for resolving a difference assigned?" | Interview AR and Sales managers |
| H3 Work happens outside the ERP | "Which systems support payment matching and exception resolution today?" | Walk through one real exception |
| H4 The effort is material | "How much effort does your team spend resolving these exceptions?" | Review the month-end ageing process |
| Control question | "Where does your finance team spend the most manual effort on reconciliation?" | Confirms this is the right problem |
Stop rule: if differences are rare or resolved within days, stop and redirect to the area the control question surfaces.
6. Business rules
| ID | Layer | Rule |
|---|
Reason code → evidence → validity (BR-3)
| Reason code | Required evidence | Valid when |
|---|
Tax rules summarised for illustration; they change. Check current rules.
7. Functional requirements (user stories)
8. Data requirements
Distributor ID, virtual account number, invoice number and amount, receipt reference and amount received, gap, expected TDS and Form 26AS match status, reason code, evidence reference, owner, SLA due date, status, maker, checker, credit note number, IRP reporting date, and a timestamp for every status change.
9. Controls and non-functional requirements
- Maker-checker above the Finance-set threshold; self-approval blocked and logged.
- No automatic write-off of unexplained gaps; tolerances set and changed only by Finance, with the change logged.
- Full audit trail per case; reassignment keeps history.
- Role-based access; daily reconciliation of case totals to the ERP.
- The ERP remains the system of record; the workflow layer (proposed: a platform such as ServiceNow) posts only approved outcomes. Integration method to confirm with IT.
10. User acceptance tests
| ID | Traces to | Scenario | Expected result |
|---|
11. Success metrics and pilot
Days deductions outstanding · share of gaps auto-classified · share of claims auto-accepted with evidence · invalid deductions recovered · credit notes reported within 30 days · zero wrong write-offs.
Pilot: one division, one month of historical receipts run offline (subject to security approval), then four to six weeks live. Targets are set from the measured baseline. Go / no-go: continue only if accuracy holds, resolution time falls against the baseline, and AR and Sales use the queue.
12. Risks and dependencies
- Remittance and evidence data quality; distributor adoption of virtual accounts and claim evidence.
- ERP integration effort and platform licensing.
- Sales agreeing scheme budgets upfront and owning dispute cases.
- Tax rules changing; thresholds and deadlines must be configurable, not hard-coded.
13. Sign-off
| Role | Name | Decision | Date |
|---|---|---|---|
| Finance Controller (sponsor) | |||
| AR lead | |||
| Head of Sales | |||
| IT / ERP owner |
Self-initiated from Cello World Ltd's public filings (FY26 consolidated, FY25 restated) and public industry research. Not client work. Tools named are proposals, not claims about Cello's systems.