The situation
A manufacturer with about 9,000 employees across fourteen countries approved capital expenditure through email. A requester filled a spreadsheet, attached it to an email, and it moved between approvers whose identity depended on the amount, the country, the cost centre and whether the item was in the annual plan.
Median time from request to final approval was nineteen days. A significant share of that was not decision time, it was the request sitting in an inbox while someone was on leave and nobody knew.
Nobody could answer basic questions: how many requests are open, where are they stuck, how long does each stage take. The finance team reconstructed this quarterly by asking people.
What we found in the architecture sprint
The rules were not documented anywhere, and they disagreed. We interviewed finance leads in seven of the fourteen countries and got seven different descriptions of the approval matrix, four of which contradicted the group policy document. This is normal and it is the most important thing to discover early, because building a workflow engine against rules nobody agrees on produces a system everyone rejects.
We spent nine days producing a single reconciled matrix and getting it signed off by group finance. That document was arguably the most valuable deliverable of the project and it contained no code.
The real constraint was governance, not technology. The client had a change advisory board meeting fortnightly, a mandatory security review, a data protection assessment and a requirement that any new system integrate with their existing identity provider before it could hold production data.
Most vendors treat this as friction to be complained about. We treated it as the schedule. We mapped every gate, found which ones could run in parallel, and started the security review and data protection assessment in week two against the architecture document rather than against finished software. That is why the first production release landed in nine weeks rather than the five or six months their previous projects had taken.
SAP was the source of truth and would stay that way. Cost centres, budgets, vendor records and the eventual purchase order all lived in SAP. Our platform had to read from it, write a purchase requisition to it, and never become a second place where a budget figure lived.
What we built
A workflow engine driven by configuration, not code. Approval routing is a declarative rule set that finance owns and can change without a deployment. Amount bands, cost centre ownership, country overrides, in-plan versus out-of-plan, and delegated authority during absence.
Making this configurable rather than coded was the decision that mattered most. Approval rules change constantly, and a system where every change is a two-week development request gets routed around within a year. Finance has made forty-three rule changes since launch without involving us.
Delegation and absence handling as first-class features. The single largest source of delay in the old process was an approver being unavailable. The platform requires an active delegate for any absence over two days, escalates automatically after a configurable interval, and shows every requester exactly who is holding their request and since when.
That visibility changed behaviour more than the automation did. Approvals that had been invisible became a public queue with names attached.
SAP integration through a read-through and write-back layer. Budget availability is read live from SAP at submission and again at final approval, so a request cannot be approved against a budget that has since been consumed. On final approval the platform writes a purchase requisition back through SAP OData and stores the returned document number.
We deliberately cached nothing that could go stale in a way that would mislead. Vendor lists are cached for an hour. Budget figures are never cached.
Entra ID for identity, with group-driven authorisation. No user administration inside the platform. Roles derive from existing security groups, which means joiners and leavers are handled by the process the company already has. This was also what got us through the security review quickly, because there was no new credential store to assess.
Audit trail on everything. Every state transition, every rule evaluation with its inputs, every SAP call and response, every delegation. Immutable, queryable, exportable. Internal audit tested it in month four and it satisfied them without follow-up.
Delivering inside the governance process
This is the part worth describing, because the engineering was ordinary and the delivery was not.
Week one and two. Architecture sprint, rule reconciliation. Security review and data protection assessment submitted against the architecture document, not against code. Both take four to six weeks in this organisation, so starting them before development meant they completed in parallel rather than in series.
Week three. Change advisory board submission for the infrastructure, which is a separate approval from the application. Approved at the meeting in week four.
Weeks three to seven. Build. Infrastructure provisioned as soon as the CAB approved it, so the application had somewhere to deploy the moment it existed.
Week eight. Penetration test by their approved supplier. Two medium findings, both fixed within three days.
Week nine. Production release to two pilot countries.
Total elapsed time nine weeks, of which roughly five were development. The other four were governance running alongside rather than afterwards. Their previous internal project of comparable size had taken seven months, most of it waiting.
Weeks ten to twenty-four. Rollout across the remaining twelve countries, two at a time, with local rule configuration and finance training for each.
What was harder than expected
Local rule variation was worse than the reconciled matrix suggested. Three countries had legally required approval steps that had not surfaced in the interviews because the people we spoke to considered them so obvious they went without saying. We found them during rollout. The configurable rule engine absorbed all three without a code change, which was the whole point of building it that way, but we should have asked a lawyer as well as a finance lead.
Migrating in-flight requests. At cutover in each country there were open requests part way through email approval chains. There is no clean answer to this. We built a lightweight import that captured the request and its approvals so far, with a manual reconciliation step, and accepted that about sixty requests across the rollout needed someone to sit down and sort them out by hand.
Getting people to stop using email. For the first six weeks in each country, requests kept arriving by email. What ended it was finance declining to process anything that did not have a platform reference number, agreed in advance and communicated clearly. Technology did not solve that. A policy did.
Results
Approximately 1,100 staff hours a month returned across the group, calculated from a time study of the old process against measured platform usage.
Median approval time fell from nineteen days to 4.2. The distribution matters more than the median: the old process had a long tail of requests taking over sixty days, and that tail is gone entirely because nothing can sit unattended without escalating.
Every approval now carries a complete audit trail. Internal audit's quarterly capital expenditure review went from a two-week exercise to a report.
Finance has made forty-three approval rule changes without a deployment, which is the number we point to when someone asks whether configurability was worth the extra fortnight.
What we would tell another team
In an enterprise, the governance calendar is the project plan. Find every gate in week one and run them in parallel against documents rather than sequentially against software. That single change was worth about four months here.
Reconcile the business rules before writing the engine, and get the reconciliation signed. If seven people describe the process differently, building any one of their versions produces a system the other six reject.
Make the rules configurable by the people who own them. A workflow platform where every policy change is a development ticket is a workflow platform that gets bypassed.