A construction business finds out whether a job made money long after it could have done anything about it.
The SAP question in engineering and construction is almost never whether a transaction posts. It is whether project cost, commitment and revenue are accurate enough, early enough, for someone to act on. That answer is assembled from procurement, subcontracts, timesheets, progress measurement and accruals — which means the things most worth testing are the ones that only reveal themselves at period end.
What makes Engineering and Construction different from a standard SAP landscape.
None of this is exotic. All of it is known. It goes wrong anyway, because the test plan is usually written against the process rather than against the way the process actually behaves here.
The work breakdown structure decides what can be known
Cost, commitment, revenue and progress all report against the WBS. If it is too coarse, nothing useful can be seen; too fine, and nobody maintains it. Testing has to prove the structure carries real transactions correctly, not merely that a WBS element can be created.
Progress is a judgement that drives a posting
Percentage complete, measured quantities and milestone achievement convert an opinion about site progress into revenue. The calculation is sensitive to configuration and to the order events are recorded in, and the same physical progress recorded differently produces a different number.
Subcontractors are procurement, cost and risk at once
Service entry sheets, back-charges, retention, advance recovery and variation orders all move project cost. Variations especially arrive mid-job, are approved out of sequence, and are frequently the difference between a profitable job and a loss.
Retention and advances span the whole contract
Money withheld at the start is released at the end, sometimes years later, under conditions. A test cycle almost never spans that, so the release side of the process is routinely unproved until it happens for real.
Sites are not head office
Goods receipts, timesheets and progress are recorded at remote locations, often late and sometimes on paper first. Any scenario that assumes prompt, in-sequence entry is not describing the business.
The failures that reach production.
Each of these is quiet. Nothing errors, nothing is flagged, and no check that reads configuration would have caught it.
Commitments and accruals behave differently after a configuration change, and the effect shows up as project margin drifting rather than as an error anyone can point at.
They arrive out of sequence by nature, which is exactly the case least likely to be in a test plan.
Because it was never tested — the test cycle finished long before any contract reached that stage.
Where we would put the effort.
Scope is agreed with you before anything starts. This is where we would argue it belongs in Engineering and Construction, and why.
Project lifecycle as one scenario
Award through procurement, subcontract, progress, billing, variation and closure — run as a continuous case rather than as separate transaction tests, because the errors live in the joins.
Period-end behaviour
Commitments, accruals, work-in-progress and cost-to-complete exercised deliberately, since this is where project reporting is actually produced.
Out-of-sequence and late entry
Site data arriving late, in the wrong order, or after period close, treated as designed scenarios.
Retention and advance recovery
The end of the contract tested at the start of the programme, because otherwise it is tested by a customer.
Industry knowledge, stated plainly.
Our exposure to engineering and construction comes from Rufouss engagements and from consultants who have worked with contracting and project-driven organisations, including the Project System, procurement and progress billing side.
Where we do not have that depth, we say so rather than take work on the assumption we will pick it up as we go. That answer has cost us engagements. It is still the right one, and it is the reason this page lists nine industries rather than thirty.
About SAP quality in Engineering and Construction.
Why so much emphasis on period end rather than transactions?
Because in a project business the number that matters — what this job is going to cost and earn — is produced at period end from commitments, accruals and progress. Individual transactions can all be correct while that number is wrong.
How do you test something that only happens years into a contract, like retention release?
By constructing the state rather than waiting for it: build project data that represents a contract at that stage and run the process against it. It is a data exercise more than a testing one, and it is the reason these processes are usually skipped.
Is Project System worth automating?
The repetitive transactional spine is. Progress measurement and variation approval usually involve judgement and are better designed as manual scenarios with prepared data than forced into scripts that prove only that a screen accepted input.
Where this work usually starts.
Take any one of these on its own, or as one stage of a longer arc.
Tell us where your Engineering and Construction programme is.
No business case needed, and a straight answer either way — including when the honest answer is that you do not need us yet.