Procure-to-pay · requisitions and ERP handoff · 2025–2026
Every level could tax an already-taxed amount
Not rounding. Tax and discount lived at several levels at once, so every level was individually defensible and the total was still wrong — collapsed into one ladder with no second rung.
How it was reported
“There are rounding errors on the requisition totals.”
What it actually was
Rounding was a fair first guess: the discrepancies were small and each level checked out on its own.
Tax and discount were applied at three levels of the same document — item line, service scope, and document. Each was correct alone. Composed, a level could tax an amount a level below it had already taxed. There was no single wrong place to find, which is why it read as rounding.
The output feeds a purchase order and an ERP handoff, so a wrong total is not a display bug — it is a number someone approves.
What shipped
- One arithmetic ladder. Tax cannot land on taxed money because the ladder has a single rung where tax happens and no second one exists.
- It holds across every grain the document has: item lines, service scopes with their own pricing and terms, and split-line multi-vendor sourcing costed where it is actually sourced rather than averaged up.
- Component-first requisitions with server-resolved cost codes derived from purpose, so mapping to a chart of accounts is configuration rather than a typed field.
- Multi-currency throughout, delivered inside the ERP revamp rather than bolted beside it.
Evidence
- repositories the change had to land across
- multiple
- to deliver the ERP integration
- 2 weeks
One ladder is what makes the rule checkable. A rule per level is a rule per level to test.
- NestJS
- MySQL
- Sequelize
- TypeScript
- Next.js
- SAP integration