Defense Contractor ERP Problems: The 7 That Put Payments at Risk, and How to Avoid Them

Why does the project keep growing into a general ledger replacement?

A controller describes the pain honestly. The real indirect rates live in a workbook. The billing analyst rebuilds every invoice pack in Excel. The incurred cost submission eats a quarter. Somebody in the room concludes that the accounting package is the problem, and the scope becomes replacing it.

That conclusion is wrong more often than it is right, and it is the most damaging scope error in this sector. A compliant general ledger is a solved, heavily audited problem, and rewriting it puts your ability to invoice at risk in order to save licence fees. Every project we have watched go badly in government contracting went badly because someone decided to replace the ledger at the same time as building the layer around it.

What is actually worth building is the edge work the packages do poorly, which is where the load bearing spreadsheets already are. A first release covering rate modelling, project cost reporting against funded value and generated billing packs on top of your existing ledger runs $85,000 to $175,000 and lands in 14 to 20 weeks in Digital Heroes delivery experience. The full platform adding compliant timekeeping, subcontractor and other direct cost workflow, incurred cost assembly and estimate at completion reporting runs $250,000 to $600,000 phased over 9 to 18 months. Keeping the ledger is what holds those numbers where they are.

What goes wrong when you migrate rate history and project cost data?

The migration nobody scopes properly is history. You need prior years of actual cost by pool and base to run any scenario, to defend a provisional rate, and to assemble an incurred cost submission that ties. That history currently lives in three places: the ledger, the controller's workbook, and a set of year end adjustments that were made in the workbook and never pushed back.

The specific defect that bites is retroactive rate change. Provisional rates get set, work gets billed against them, and final rates settle later. If the migration copies a single current rate onto historical transactions, every prior period silently restates and nothing reconciles to what you actually invoiced. The correct model treats pools, bases, allocation sequence and effective dates as versioned records, so any period can be recalculated under any rate set and the system can show which rate version applied to a given invoice and why.

The second defect is unallowable cost. If your screening has been a year end sweep, the historical data has no reliable flag at transaction level, so the migrated ledger cannot answer questions the submission will ask. Plan a period where screening runs at entry in the new system while the prior years are reconstructed and flagged deliberately, and treat that reconstruction as scoped work rather than a data load.

Why do the Costpoint, Unanet and payroll integrations break after launch?

Reading from an accounting package is a different exercise from writing back to it, and quotes routinely conflate the two. Costpoint, Unanet GovCon and JAMIS Prime each expose data very differently, and a read integration that works on day one can break when the vendor changes a schema in an upgrade you did not control the timing of.

The breakages that actually hurt are the ones that fail quietly. A project setup created in the package but not mirrored into the layer means costs land against a project the reporting system has never heard of, and they disappear rather than erroring. A labour category renamed in payroll means time and materials billing stops matching a negotiated rate. A government invoicing portal changes an accepted format and submissions start rejecting on a technicality that reads like a system fault.

Three practices prevent most of it. Reconcile continuously rather than at period close, so a total that does not match the ledger surfaces within a day. Fail loudly on unknown identifiers rather than creating records on the fly, because an auto created project is how a cost pool quietly gains a base it should not have. And keep the portal format as configuration with a validation step before submission, so a format change is an afternoon rather than a billing outage.

What happens when floor check timekeeping and unallowable screening are not covered?

DCAA floor checks are unannounced. An auditor walks up to an engineer, asks what they are working on right now, and compares the answer to the timesheet. The rules behind that are unglamorous and non negotiable: the employee records their own time, records it daily, and any change after submission carries a reason and a supervisor approval preserved permanently.

Packaged timekeeping is generally compliant until your workforce breaks the assumption behind it. Field service technicians at a government site with no network cannot record daily on a connected app. Staff working four charge codes in a day need to see remaining funded hours before they charge, not in a month end report. Subcontractor labour has to sit against the same work breakdown structure while being priced differently and never touching your fringe pool. Exempt staff under total time accounting change the effective hourly rate for every hour worked that day, which standard timesheets handle awkwardly.

The architectural decision that makes this survivable is an append only event store rather than an editable timesheet table, chosen on day one. It costs nothing extra at the start and is genuinely expensive to retrofit once an auditor has asked the question. Pair it with offline capable daily entry that preserves the original entry timestamp on sync, charge code visibility driven by actual contract authorisation, and funded value warnings at the point of entry.

Should you build custom or configure what you already own?

If you are under roughly $25M in revenue, run fringe, overhead and general and administrative pools with straightforward bases, and your contract mix is mostly one type, buy PROCAS or Unanet and spend the difference on a good DCAA consultant. That is the honest answer and it applies to more contractors than the industry admits. A build would be an expensive way to own a problem someone else has already solved and keeps solving as regulation moves.

Buy also if you are chasing your first cost reimbursable award and need to pass a preaward accounting system survey inside ninety days. Nothing custom is audit ready in that window, and the survey is a gate you do not get to negotiate.

Configure rather than build when the gap is genuinely a configuration gap. Costpoint models pools and contract types properly and is the most capable of the mainstream options at it. If your pool structure is expressible in the product and nobody has actually tried, hire the consultant before hiring the engineers. The build case appears when the controller's workbook has become load bearing, when a bid cycle stalls because nobody can price a scenario quickly, when your billing analyst spends more time in Excel than in the system you pay for, or when a reorganisation you need for business reasons is being delayed by what the configuration will allow.

How do hidden costs get into the quote?

Pool count and base type are the biggest unpriced driver. Each additional allocation step multiplies the test cases, and a value added base rather than a total cost input base changes the arithmetic in ways that ripple through every downstream schedule. A quote written against three pools does not survive six pools and a site rate.

Multiple segments or a joint venture with separate rate structures is the second. So is Cost Accounting Standards coverage, because a covered contractor carries disclosure statement consistency requirements that constrain what the system is permitted to do, and those constraints are design inputs rather than acceptance criteria.

Government invoicing portal formats are routinely quoted as one line and are not. Each supporting schedule a contracting officer expects is real work, and the packaging around an invoice is where the manual effort actually sits, not in the invoice itself.

Then there is earned value. If a contract requires a validated earned value management system, that is its own programme with its own criteria and surveillance, and folding it into an accounting build is how timelines double. Internal estimate at completion reporting for programme managers is a different and much cheaper thing, and it is what most contractors actually need. Scope them separately and say so in the statement of work.

What separates a build that works from one that fails here?

History is never overwritten. A retroactive rate change recalculates affected periods and produces an adjustment trail. If a developer proposes updating the rate field and rerunning the report, they have not understood the audit problem and everything they build will be wrong every year until the rate settles.

Billing instructions are structured data attached to the task order, not a note in a shared folder. The system generates the invoice, the supporting schedules and the portal ready file, then holds the whole package immutably so a payment questioned eighteen months later can be answered with exactly what was sent. Funding thresholds fire notifications automatically, because the limitation of funds letter is a contractual obligation and missing it is an unforced error.

The incurred cost schedules are queries against the same versioned rate data used for billing all year, so they tie by construction rather than by reconciliation. That single design choice is what turns a two month assembly into a two day review.

Finally, get the right people in the right meeting. Bring your DCAA consultant into the design review rather than the acceptance test, because the cheapest compliance defect is the one caught on a whiteboard. And settle ownership of the repository, the cloud accounts and the right to hire another firm in writing before kickoff. Your business systems have to stay auditable and maintainable independently of any one vendor relationship.