No. 11

Specifying the ERP module — and catching the errors the implementer missed

Wrote the requirements for the project-system module and found two configurations that would have baked a revenue-recognition error into the system.

SAP PSIND AS 115SD account determination (VKOA)Results Analysisrequirements engineering

How it works — the logic, animatederp blueprint

Logic animation in productionThe core concept of this build, animated — arriving shortly.

Context

To put project-based revenue recognition on a proper system footing, the business needed to activate the ERP's project-system module — the part that handles work breakdown, costing, and milestone billing for long-running contracts. An implementation partner had a prior blueprint on file. Activating it as-is would have been the path of least resistance.

Challenge

Translate what finance needs — IND AS 115-compliant revenue recognition, costing, and billing that ties to project progress — into a precise requirements specification the implementation team could build from, *and* check the existing blueprint rather than trust it.

What I built

A full user-requirements specification for the module: work-breakdown structure, cost planning and capacity, milestone billing plans driven by project finish dates (to kill the manual date mismatches that cause missed billing), and the revenue-recognition configuration — written so the implementation team could configure without guessing.

The decisive part was the gap analysis against the existing blueprint. I found two configurations that weren't gaps — they were errors that would have produced IND AS 115-non-compliant entries:

Revenue account determination routed an up-front milestone straight to P&L revenue, where it should post to a contract-liability account until the obligation is met.
The results-analysis / settlement setup would have credited revenue in a way that double-counts earned vs. unearned, instead of cleanly splitting revenue earned, contract asset, and contract liability.

I flagged both as mandatory sign-off items *before* configuration — because shipping them would have perpetuated the exact misclassification a restatement had just been needed to fix.

Outcome

A specification precise enough to build from, and two latent errors caught at the blueprint stage — when a config change is a line in a document, not a year of mis-posted entries to unwind later.