DCAA Compliant Accounting Software: What Really Happens When Your Business System Is Found Inadequate

Why the accounting system is the contract

Most software failures cost you time. This one can cost you the ability to invoice. Under the DFARS business systems rule, a contracting officer who receives a report of a significant deficiency in your accounting system can withhold a percentage of payments on every affected contract until you correct it. That is not a line item, that is your working capital. A contractor with $40M in cost-reimbursable work and a withhold in place is suddenly financing the government while it rewrites its rate structure.

So the buying question is not which package has the nicer dashboard. It is whether the system can prove, to an auditor who is looking at it years later, that a dollar of cost was recorded to the right contract, the right CLIN and the right indirect pool on the day it was incurred, and that nobody edited it afterward without leaving a trail. Deltek Costpoint, Unanet GovCon, JAMIS Prime and PROCAS all exist because commercial ERP (Enterprise Resource Planning) cannot do this. QuickBooks with a job-costing plugin will pass an SF 1408 preaward survey at ten people and fall apart at eighty.

Here is the position we take with GovCon CFOs, and it is not the one an agency is supposed to take: you should almost never build a replacement general ledger. The ledger is a solved, boring, heavily audited problem, and rewriting it puts your billing at risk to save license fees. What is worth building is everything the packages do badly at the edges, which is where a controller currently keeps a spreadsheet that the entire company depends on and nobody has ever audited.

Problem 1: the real indirect rates live in one person's workbook

Ask a GovCon controller where the provisional rates come from and you will usually get shown a workbook. Fringe pool, overhead pool with its own base, G&A on a value-added or total cost input base, maybe a materials handling pool and a separate site rate for work performed at a government facility. The workbook applies them, forecasts them for the year, and compares provisional to actual. The accounting package holds a simplified copy of this that gets updated after the fact.

Costpoint models pools properly and is the most capable of the four at this. The cost is that pool and base changes are configuration work, often through a consultant, and a contractor who reorganises into two segments mid-year discovers the change is a project rather than an afternoon. Unanet is lighter and considerably easier to live with, but its pool structures are more opinionated, and organisations with unusual base definitions end up back in Excel for the parts it will not express. PROCAS is priced for small business and is honest about that. None of them will happily run three parallel rate scenarios so a CFO can see what a proposed reorganisation does to competitiveness on a bid due Friday.

What a custom build does: treat the rate structure as versioned data rather than configuration. Pools, bases, allocation sequence and effective dates become records, and any period can be recalculated under any rate set. That gives you three things the workbook cannot. You can show an auditor exactly which rate version applied to a given invoice and why. You can run a proposed structure against last year's actuals in minutes during a bid. And when the controller retires, the logic stays.

Problem 2: timekeeping has to survive a floor check, not just collect hours

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

The packages all ship timekeeping and it is generally compliant. Where it breaks is when your workforce does not fit the assumption. Field service technicians at a government site with no network. Staff who work across four charge codes in a day and need to see remaining funded hours before they charge. Subcontractor labor that must be recorded against the same WBS but priced differently and never touched by your fringe pool. Uncompensated overtime for exempt staff, where the total time accounting method changes the effective hourly rate for every hour that person worked that day, which the standard timesheet handles awkwardly at best.

What a custom build does: an offline-capable daily entry that syncs with the original entry timestamp preserved, charge code visibility driven by actual contract authorisation rather than a static list, funded-value warnings at the point of entry rather than in a month-end report, and a change log that no role in the system can delete. That last constraint drives the architecture: an append-only event store, not an editable table. It is a design decision that costs nothing extra if made on day one and is very expensive to retrofit after an auditor asks.

Problem 3: three contract types on one ledger, three different invoices

A cost-plus-fixed-fee task order bills actual cost by element with fee calculated on the base, and it needs a public voucher assembled with supporting detail. A time and materials contract bills hours at negotiated labor category rates, which means the person's qualification against that category has to be defensible. A firm fixed price contract bills on milestones or a payment schedule and does not care about actuals at all, except that you still have to record them to know whether you are losing money. Many contractors run all three, plus an IDIQ with dozens of task orders each carrying its own funding, period of performance and billing instructions.

Every package produces invoices. What they produce badly is the assembly around them: the supporting schedules a particular contracting officer wants, the payment request formatted for the government invoicing portal, the limitation of funds notification triggered at the right percentage, the retention withheld and later released on fee. So a billing analyst exports to Excel, rebuilds the pack, and uploads it manually. Multiply by the number of active task orders and that is a full-time role doing work that is entirely rules-based.

What a custom build does: billing instructions become structured data attached to the task order, not a note in a folder. The system generates the invoice, the supporting schedules and the portal-ready file, then holds the whole package immutably so that when a payment is questioned eighteen months later you can reproduce exactly what was sent. Funding thresholds fire notifications automatically, because the seventy-five percent letter is a contractual obligation and missing it is an unforced error.

Problem 4: the incurred cost submission eats a quarter

Once a year you owe an incurred cost submission within six months of fiscal year end, and it is not one report. It is a set of interlocking schedules covering claimed rates, pool detail, base detail, contract-by-contract claimed cost, subcontract listings, executive compensation and reconciliation back to the financial statements. Most contractors assemble it by exporting the year to Excel and having the controller and an outside consultant stitch it together over several weeks, then discover a schedule does not tie and go back.

What a custom build does: the schedules are queries against the same versioned rate data used all year, so they tie by construction rather than by reconciliation. Unallowable costs are flagged at transaction entry against your own screening rules rather than swept up in a year-end review, which is also the only way to catch them while anyone still remembers the transaction. The submission becomes a two-day review instead of a two-month build.

What this costs and how long it takes

A first release covering the rate engine, 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. A full platform adding compliant timekeeping with offline capture, subcontractor and other direct cost workflow, incurred cost schedule assembly, and estimate at completion reporting for program managers runs $250,000 to $600,000 phased over 9 to 18 months.

What pushes the number up in this sector specifically: the number of pools and whether any base is value-added, because each additional allocation step multiplies the test cases. Multiple segments or a joint venture with separate rate structures. Cost Accounting Standards coverage, since a CAS-covered contractor carries disclosure statement consistency requirements that constrain what the system may do. Government invoicing portal formats. And earned value, which is a genuinely different discipline: if you need a validated EVM system rather than internal EAC reporting, that is its own program and you should scope it separately.

What keeps the number down: leaving the general ledger where it is. Every project we have seen go badly in this category went badly because someone decided to replace the ledger at the same time.

Build versus buy, and when buying is clearly right

Buy if you are under roughly $25M in revenue, run fringe, overhead and G&A with straightforward bases, and your contract mix is mostly one type. PROCAS or Unanet will serve you well for a few tens of thousands a year and a build would be an expensive way to own a problem someone else already solved. Buy if you are pursuing your first cost-reimbursable award and need to pass a preaward accounting system survey in ninety days, because nothing custom will be audit-ready in that window.

Build the layer, keep the package, 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 your ERP configuration will allow. Those are all symptoms of the same thing: your operating model has outgrown the vendor's assumptions, and the gap is being filled by people.

The line we draw is this. If the compliance requirement is generic to GovCon, buy it. If the requirement is specific to how your company is organised and how your contracts are written, build it, and integrate rather than replace.

How to choose a developer for government contract accounting work

Ask them to explain the difference between a provisional rate and a final rate, and what happens between the two. If they cannot, they will build you a reporting tool that is wrong every year until the rate settles. This is the single fastest filter.

Ask how they will handle a retroactive rate change. The correct answer involves recalculating affected periods and producing an adjustment trail, not overwriting history. If they propose to update the rate field and rerun the report, they have not understood the audit problem.

Ask what they have integrated with. Costpoint, Unanet and JAMIS all expose data very differently, and reading from a package is a different exercise from writing back to it. Ask for the specific system and the specific direction, and ask whether they have handled a government invoicing portal submission format end to end.

Ask who owns the code, the repository and the cloud accounts, and get it in the contract before kickoff. At Digital Heroes you own all three from the first commit. Then bring your DCAA consultant into the design review, not the acceptance test. The cheapest compliance defect is the one caught on a whiteboard.