Inteldefense
An ERP Will Not Fix a Failed Audit
The department has never passed a full financial statement audit. A new ERP does not change the evidence problem that causes the failure.
The Department of Defense has never passed a full financial statement audit. Its independent auditors issued another disclaimer of opinion on the fiscal year 2024 statements, which means they could not obtain enough evidence to express an opinion either way.
That sentence has survived several generations of enterprise resource planning systems. It will survive the next one unless somebody changes what the modernization is for.
An ERP is a ledger, not evidence
An ERP does two things well. It gives an organization a common chart of accounts and a common transaction model, and it produces a consolidated view that used to require a spreadsheet exercise.
Neither of those is what an auditor tests.
An auditor tests assertions. Does the recorded asset exist. Is the recorded liability complete. Is the value right. Is the transaction recorded in the correct period. For each of those, the auditor asks for evidence that is independent of the system's own claim.
An ERP that records a transaction correctly and cannot produce the supporting document behind it has improved reporting and not auditability. That distinction is the whole problem, and it is easy to lose inside a multi-year implementation.
The three assertions that break first
Existence. Somebody has to show that the inventory item, the property, or the receivable is real. In a large organization that means physical counts, reconciliations, and a sample that an auditor selects. No software fixes a count that was never done.
Completeness. This is the one that catches people. The question is not whether the transactions in the system are recorded correctly. It is whether all the transactions that should be in the system are in the system. If a feeder system records obligations in a local database and reconciles to the ERP monthly, completeness depends on that reconciliation, and on whether the local database is trustworthy.
Valuation. Estimates, depreciation, and provisions require assumptions and a documented method. An ERP can hold the number. It cannot hold the judgment, and the judgment is what the auditor examines.
The audit fails on the evidence around the ledger, not on the ledger.
Feeder systems decide the outcome
Most of the department's financial activity originates outside the ERP. Contract payments, payroll, inventory movements, and property records are created in systems that feed the ledger.
Each of those interfaces is a place where a record can arrive without its supporting detail, or arrive late, or arrive twice. Each is a place where an auditor will ask a question the ERP cannot answer, because the ERP only knows what it was told.
Programs that scope modernization to the ERP's functional footprint spend years replacing the accounting engine and leave the feeder systems untouched. The audit finding that follows is the same finding, in a newer system.
Programs that scope modernization to the evidence chain do something harder and more useful. They map every feeder interface, define the evidence that must travel with each transaction, and make the interface reject a record that arrives without it. That is unglamorous work in the middle of a large program, and it is the work that changes the audit result.
What to put in the requirements
If audit readiness is a stated goal of an ERP modernization, four requirements belong in the document, and they belong there before the vendor selection.
Every transaction carries a link to its source evidence, and the link survives archival and system migration.
Every interface rejects a record that fails its validation rule, and records the rejection for review rather than dropping it.
Every reconciliation is automated, logged, and reproducible as of a date, not just as of today.
Every material estimate has a documented method, a named owner, and a version history.
None of those are exotic. All of them are routinely deferred because they do not demo well and they do not reduce the license count.
The timeline problem
An ERP modernization is a decade scale effort. A financial statement audit is annual.
That mismatch is why the audit finding does not wait for the program. Each year the auditors return, sample transactions, and report what they could not verify. The program produces a new system on a five to seven year horizon, and the findings accumulate in the meantime.
The only way to shorten that loop is to fix evidence in the current system while the new one is being built. Clean up the feeder interfaces now. Automate the reconciliations now. Document the estimates now. Those changes improve the current audit and they carry into whatever replaces the system, because they are process changes rather than software changes.
Programs that wait for the new system to fix the old problem usually discover that they have moved the problem, with a larger integration surface.
What audit readiness requires is not a better ledger. It is a shorter path from a number on a statement to the document that proves it.
The services that make progress on this are the ones that treat audit readiness as an evidence project with an ERP component, rather than an ERP project with an audit goal. They assign people to the interfaces, they measure how long a sample takes to support, and they fix the worst case first.
The system matters. The evidence matters more, and it is the part that no implementation partner will own for you.
A clean audit is not a software outcome. It is a records outcome that software can make cheaper.