The “We’ll Just Configure It” Trap: Why ERP Customization Puts GovCon Compliance at Risk

 

Four words end more GovCon ERP evaluations badly than any vendor demo ever could: “We’ll just configure it.”

It sounds like confidence, but usually means the opposite. Somewhere in the evaluation, a gap surfaced between what the system does natively and what DCAA expects to see. Instead of treating that gap as a disqualifying finding, the team decided to build around it. That decision is the moment when GovCon ERP customization stops being a helpful tailoring step and becomes a compliance liability.

That decision rarely gets revisited until years later, usually during an audit, when the workaround built to solve a demo-day problem has become the accounting team’s full-time job.

 

 

Why “We’ll Just Configure It” Feels Like the Right Call

Commercial ERP platforms are powerful tools in their own right. Most can handle multi-entity structures, procurement workflows, and complex reporting without much strain. Vendors know this, and their sales teams are trained to answer almost any compliance question with some version of “the platform can be configured to do that.”

Technically, that is often true. A configurable platform is not the same as a platform built around GovCon accounting requirements from the start. Indirect rate structures, labor distribution, unallowable cost segregation, and contract-level auditability either live natively in the system’s architecture or are recreated on top of it through custom fields, connected spreadsheets, and manual review steps.

Nobody sits down and decides to build a fragile system. It happens gradually. A rate calculation that does not quite fit the native structure gets moved into a spreadsheet “for now.”

A labor charging exception is handled via email approval instead of a workflow. Each decision looks small and reversible in isolation. None of them get revisited once the implementation is declared finished.

The pressure to say yes is real. Implementation timelines are tight, budgets are set, and a vendor who can point to a configuration path forward looks like the path of least resistance compared to switching platforms mid-evaluation. That pressure is exactly why the phrase is dangerous. It resolves the immediate conversation without resolving the underlying question of whether the platform was ever the right foundation.

Customization Is Not the Problem. Recreating Compliance Is.

Every ERP implementation requires some tailoring. That was never the issue, and no accounting advisor worth hiring will tell a contractor to avoid configuration altogether.

The trap is specific: it is the attempt to recreate core DCAA-compliant ERP functionality. This kind has to hold up under a DCAA audit, relying on disconnected workflows and manual procedures rather than the system’s own design. At that point, the burden of compliance quietly shifts from the ERP to the people running it. Four consequences follow, and they tend to arrive in a predictable order.

Consequence One: Compliance Shifts From the System to the Accounting Team

Once core GovCon logic lives in spreadsheets and manual reviews rather than in the ERP itself, the system stops being the control. Your team becomes the control.

Every indirect rate calculation, every unallowable cost flag, every labor charging exception now depends on someone remembering to handle it correctly, every single time. That is a different kind of risk than a software limitation. A missing feature is a known gap you can plan around. A person who has to catch every exception manually is a control that degrades the moment they take a vacation, change roles, or leave the company.

This is also where institutional knowledge becomes a liability instead of an asset. The employee who built the workaround understands exactly why it works. Nobody else does, and there is rarely a document explaining it, because the workaround was never treated as a formal part of the accounting system in the first place.

Consider what this looks like in practice. A controller sets up a spreadsheet to calculate an indirect rate the ERP could not handle natively, gets it working, and moves on. Two years later, that controller takes another job.

The person who inherits the file has no context for why certain cells reference specific accounts or why one column is manually adjusted every quarter. The knowledge did not transfer with the job description. It left with the person.

Consequence Two: Processes Become Impossible to Document

Workarounds accumulate quietly. A spreadsheet here, a manual reconciliation there, a review step nobody wrote down because everyone on the team already knew to do it.

Six months into an implementation, nobody can produce a clean process map of how indirect costs are actually allocated, because the real process lives across three people’s memories, a shared drive folder, and a set of macros one person maintains. Better recordkeeping after the fact will not fix this, because the workaround was built to solve an immediate need rather than to be explained to someone else later.

This matters more than it sounds like it should. DCAA’s pre-award checklist exists specifically to confirm that a contractor’s accounting system, not a set of informal habits layered on top of it, can reliably produce accurate, auditable cost data. A system that only works because of undocumented tribal knowledge does not meet that bar, even if the numbers it produces are correct.

Consequence Three: Audit Defense Depends on People Instead of Controls

DCAA audit steps focus on whether a system is designed to prevent an error before it happens, not on how sharp the person catching it afterward is.

When the honest answer to “how do you catch unallowable costs” is “our controller always catches that,” the business is one resignation, one busy week, or one new hire away from a finding. Auditors are trained to look past confident verbal explanations and ask for the underlying control. A workaround that depends entirely on a specific person’s diligence works only until that person has a bad day, and calling it a control does not change that.

This is precisely the gap FAR Part 31 is designed to close on the cost side, and it is why an accounting system built around manual compensation for missing functionality tends to draw more audit scrutiny over time, not less. Auditors who find one workaround start looking for others.

Consequence Four: Scaling Breaks Everything

Manual workarounds are fragile by design, even when they are well built. They hold together at a small contract volume because a handful of people can still track everything by hand and catch errors before they compound.

Add contracts, add headcount, add a second office or a new prime relationship, and the same workarounds that felt manageable start failing in ways that are expensive to unwind. A spreadsheet that tracked twelve contracts cleanly becomes unreliable at forty, right around the same time a new prime contract starts demanding audit-ready reporting on a tight deadline. The business does not receive a grace period to rebuild its accounting infrastructure once growth has already occurred. It has to operate through the transition with the same fragile system that got it there.

This is the same pattern that shows up whenever a chart of accounts or reporting structure was never built with room to grow. The fix costs far more once two years of transactions have been coded around the limitation than it would have cost to build correctly from the start.

What GovCon Software Implementation Should Look Like Instead

The strongest GovCon ERP environments do not eliminate customization. They limit it to the areas where customization actually belongs- cosmetic reporting preferences, department-specific dashboards, non-compliance workflow tweaks, and keep the compliance-critical logic embedded directly in the system’s architecture.

That means labor charging controls, indirect rate calculations, and unallowable cost segregation are built into the platform’s native design, not layered on top of it after the fact. An auditor asking “show me how this works” gets a system walkthrough instead of a verbal explanation of a spreadsheet macro, and the person who built the process can leave the company without taking the process with them.

Getting there usually requires asking a harder question earlier in the evaluation, before a single license is purchased: can this platform do this natively, or are we already planning to configure around a gap? If the honest answer is the second one, that gap is worth resolving before implementation, not after the first audit finding.

The Real Question to Ask Before You Configure Anything

The next time an ERP conversation reaches “we’ll just configure it,” the useful follow-up is not whether the configuration is possible. It almost always is. The useful follow-up is who will be responsible for that configuration working correctly every single month, and what happens to that responsibility when that person is out sick, promoted, or gone.

If the honest answer involves a specific person’s memory rather than the system itself, that is the moment to slow down, not speed up. Evaluate whether the platform can be configured properly within its own architecture, or whether the business is quietly signing up to run its compliance program on a spreadsheet instead of an accounting system.

If you are in the middle of evaluating or implementing a GovCon ERP and are not confident which side of that line your configuration decisions fall on, that is worth a second look before it becomes an audit finding. Reach out to the CPA Department to review whether your current system design is carrying the compliance weight it should, or whether your team has quietly started carrying it instead.

 

 

Frequently Asked Questions

What does “we’ll just configure it” actually mean in an ERP evaluation?

It usually means a compliance gap surfaced during the demo or evaluation. Instead of resolving it before purchase, the team plans to recreate the missing functionality through custom workflows or spreadsheets after implementation.

Is ERP customization always a compliance risk for government contractors?

No. Routine customization, like report formatting or department dashboards, is normal. The risk arises when core compliance functions, such as indirect rate calculations or unallowable cost segregation, are rebuilt outside the system rather than within it.

How do I know if my ERP setup is compliant or just a manual workaround?

Ask whether a new employee could explain the process based on the system documentation. If the honest answer depends on one person’s memory or an undocumented spreadsheet, it is a workaround rather than a compliant system control.

What happens during a DCAA audit if my accounting system relies on workarounds?

Auditors look for evidence that controls are built into the system rather than dependent on individual diligence. Finding one undocumented workaround often prompts closer scrutiny of the rest of the accounting environment.

How do I fix an ERP that already has too many workarounds?

Start by mapping which compliance functions currently run outside the system, then evaluate whether the platform can support them natively before deciding whether to reconfigure, add a module, or move to a different system.