Allocation is a reading problem first
Sorting costs into pools sounds like a lookup problem — check the account code, drop the amount into the matching bucket, done. In practice, almost all of the actual difficulty sits earlier than any lookup: getting an accurate amount, vendor, description and cost objective out of a document that was never designed with a specific cost pool in mind.
A vendor invoice, a payroll register, an expense report — each carries the raw figures a pool needs, printed in whatever format that vendor or payroll provider happens to use. Allocation that starts from a wrong or inconsistently read figure produces a wrong pool total, no matter how careful the sorting logic is afterward.
Why this isn't a simple lookup
Two vendors rarely format an invoice the same way. One prints a single lump-sum monthly charge for facility services; another itemizes separate lines for rent, utilities and maintenance that need to be summed to get the equivalent figure. A payroll register might report an employee's hours as one blended total or split by cost objective already, depending on the payroll provider.
Getting a genuinely usable figure out of each document means reading past the layout a vendor or payroll provider happens to use and finding the actual underlying number allocation needs — a task that's manageable for a handful of documents and increasingly error-prone the more invoices and pay periods are involved.
What consistent allocation actually means
Consistent allocation means the same kind of cost is found and sorted the same way across every document, every period, even when a vendor's invoice layout shifts slightly from one month to the next — a line renamed, a new fee added, a summary page reformatted.
That consistency is what makes a pool total defensible over time. An overhead pool that looks like it shifted because one recurring vendor's invoice quietly stopped being coded the same way isn't a real cost shift — it's a change in method disguised as a change in spend, and it's exactly the kind of gap a careful auditor eventually catches, usually at an inconvenient moment.
Why split invoices are the riskiest figure
A single facility invoice that covers space used by both an operating group and corporate admin — needing a split between an overhead pool and a G&A pool — is where an allocation is most likely to misstate a pool if it isn't caught. The invoice arrives as one amount, and applying the wrong split percentage, or forgetting to split it at all, either overstates one pool or understates another.
Left unflagged, a single large facility invoice allocated entirely to the wrong pool can meaningfully shift a rate — an error that's easy to make once, under deadline pressure, and easy to repeat every period afterward if nobody catches it the first time.
Why the same vendor means different pools
A single vendor can bill costs that belong in more than one pool over the course of a year — an IT services vendor might invoice for a corporate-wide system upgrade one month (G&A) and for project-specific support the next (direct or overhead, depending on the contract). Allocating every invoice from the same vendor to the same pool without reading each invoice's actual content produces a pool total that looks precise and isn't.
| Vendor type | Where the variation usually shows up |
|---|---|
| Facility and utilities | Whether a shared building is split by square footage between overhead and G&A |
| IT and software | Whether a system serves corporate-wide use (G&A) or one operating group (overhead) |
| Professional services | Whether legal or accounting work is contract-specific or corporate-level |
| Insurance | Whether a policy covers the whole company or one facility or division |
This is exactly why reading and categorizing are kept as two visible steps here rather than one opaque one. Getting each invoice's raw figures and description right is a document-reading problem this feature is built for. Deciding how your cost accounting policy assigns a given vendor or cost type to a pool is a judgment call that stays with your team, applied consistently once made.
What gets read
| Field | Typical source |
|---|---|
| Vendor, invoice number, date, amount | Invoice header |
| Line-item description and cost type | Invoice body |
| Employee, hours, gross wages, benefits | Payroll register |
| Existing account or cost-center code, where present | GL export or invoice coding stamp |
How it works
Upload invoices and payroll registers
For every document the pool allocation needs to cover, however differently each is laid out.
Each document is read
Amounts, vendor, description and existing coding pulled with a confidence score.
Figures sorted toward each pool
The same categories applied consistently, based on your existing coding or a clear cost description.
Ambiguous cost objectives flagged
A split invoice or an unclear description recognized rather than allocated by default.
Exported
Excel, CSV or JSON, with every figure traceable to its source document.
An invoice, allocated
A facility services invoice reports a monthly charge of $18,400 covering a building shared between a project-specific operating group and corporate administration, presented as one blended monthly total rather than a clean itemized split.
| Component | Amount |
|---|---|
| Overhead pool (per established square-footage split) | $12,880 |
| G&A pool (per established square-footage split) | $5,520 |
| Total (matches invoice's own amount) | $18,400 |
Because the split is flagged rather than assumed, the pre-established square-footage percentage is confirmed and applied consistently — the same way it was applied to this vendor's invoice every other month that year — rather than left to whoever happens to be doing the coding that particular week.
Handling mid-year policy changes
A cost accounting policy occasionally changes mid-year — a new cost center added, a pool split into two, an allocation base redefined. Applying a mid-year change consistently to every document from that point forward, without inadvertently reapplying it retroactively to documents already coded under the old policy, matters for keeping the rate schedule internally consistent within the fiscal year.
Each document's allocation is tied to the coding rules in effect at the time it's processed, so a policy change is applied going forward from when it's made — the same discipline a careful manual process follows, without depending on someone remembering the exact effective date months later.
Manual vs. automatic
| Manual | Automatic |
|---|---|
| Invoices coded by hand, differently depending on who's doing it | The same coding logic applied consistently every period |
| Split invoices allocated from memory or a rough estimate | Split percentages flagged for confirmation and applied consistently |
| Coding errors found only during an audit sample | Ambiguous or unusual coding flagged as it's processed |
| Redone by hand as invoice volume grows | Same method applies regardless of document count |
From one pool to a full CAS structure
A small contractor with one overhead pool and a simple G&A pool is a manageable manual exercise. A larger CAS-covered contractor with segregated engineering and manufacturing overhead pools, a material handling pool and a corporate G&A pool multiplies the number of documents that need reading and sorting every period without multiplying the staff time available to do it.
Sorting each document the same way regardless of pool structure keeps the per-document effort flat as the structure grows more complex, with each pool's own coding rules still applied correctly to its own figures.
Who uses this
Government contractor controllers and accountants
Invoices and payroll registers sorted into pools the same way every period, without a manual re-coding pass.
Compliance and contracts managers
Each vendor's specific costs read and sorted independently, then rolled up into pool totals.
Outside CPAs preparing rate schedules
A verified, traceable allocation received rather than raw invoice and payroll PDFs to work through.
Teams preparing for a DCAA audit sample
Every allocated figure traceable to its source document the moment an auditor asks for support.
Edge cases worth knowing
A vendor invoice that includes both an allowable service charge and a clearly unallowable cost — a late fee or a finance charge, for instance — needs the two separated rather than the whole invoice allocated as one figure, since only the allowable portion belongs in a pool billed to the government.
A payroll register entry for an employee who transferred between cost centers mid-period needs their hours split at the transfer date rather than allocated entirely to either the old or new cost center, and is flagged for that split confirmation rather than assigned by default.
Why consistency matters more than speed
An allocation done quickly but inconsistently from period to period is worse than one done carefully but the same way every time — an inconsistent allocation produces a rate trend that doesn't actually reflect the business's cost structure, which is precisely the kind of gap a careful auditor eventually notices.
Reading the same categories the same way every period, with every deviation flagged rather than silently absorbed, is what keeps the reported rate trustworthy to the contracting officers and auditors relying on it.
What a confidence score actually tells you
Every allocated figure carries a confidence score, and it's worth being specific about what that means. A high score means the figure was read from a clear, well positioned printed number with no ambiguity about which line it belongs to — not that it necessarily matches your specific pool definition.
A lower score flags exactly where a human look is worth the time: a blended invoice total, a figure split across a page break, a cost description that doesn't match the expected pattern. Reviewing the handful of flagged fields each period, rather than re-checking every figure from scratch, is what makes the whole process fast without becoming careless.
What this doesn't do
Doesn't apply your own cost accounting policy automatically
It reads and separates the raw figures; mapping them to your specific pool structure stays your call.
Doesn't determine cost allowability
It flags ambiguous or unusual cost descriptions; resolving allowability under FAR 31.205 stays a human decision.
Doesn't calculate your final indirect cost rate
It organizes pool and base figures; the rate calculation and its documentation is a separate step your team or advisor handles.
Doesn't replace your accounting or compliance team
It surfaces figures and inconsistencies; interpreting them stays with your team.
Getting your first invoice allocated
There's no setup step required before the first allocation — no pool list to configure in advance, no coding taxonomy to define up front. Upload the current period's invoices and payroll registers and the allocation runs against them directly, surfacing every field a standard pool schedule typically needs.
The first period is also the natural point to note how your cost accounting policy defines each pool — since there's no prior period yet to compare against, this is the baseline every future period's consistency check measures against.
Most teams run their first allocation against a recent, already-familiar month before relying on it for a full fiscal year — a useful way to confirm every figure lines up with what you'd expect from documents you already know well, before trusting it on a period you haven't reviewed by hand.
Why an audit trail matters here specifically
Indirect cost pool figures get scrutinized closely and specifically — by a DCAA auditor sampling individual invoices during an incurred cost audit, by a contracting officer reviewing a proposed rate, occasionally by your own internal compliance review. Each of those readers eventually asks the same question about at least one figure: where did this number actually come from, and why was it coded to this pool. An allocation that can answer that instantly, for any figure, is worth more than one that's merely fast to produce.
Every allocated figure keeps a reference back to its source document, the page it was read from, and the confidence the extraction assigned to it — not as an afterthought, but as the same output every figure carries, so answering “where did this come from” is a lookup, not a research project during an active audit.
Onboarding a new fiscal year
Starting a new fiscal year's allocation doesn't require reconfiguring anything from the prior year, assuming the pool structure stays the same. New invoices and payroll registers are read the same way as the prior year's, using the same category definitions already established, so the new year's documentation slots into the same consistent structure rather than starting a separate, parallel process.
The one thing worth doing deliberately at the start of a new fiscal year is confirming, on the first few documents, that the coding still matches expectations — a vendor with a changed invoice format, or a new cost center added since the prior year, is easiest to catch and correct in the first month, before several periods of history build up under a mapping that needs revisiting.
Security and privacy
Uploads are encrypted with TLS from end to end.
Processing runs on infrastructure with SOC 2-aligned controls.
Original documents are deleted shortly after processing.
Nothing you upload is ever used to train AI models.
For financial and payroll data tied to government contract billing, that matters — details are on the security page.
Feeding this into an existing system
Allocated figures rarely need to live only inside an exported spreadsheet. A contractor that already maintains its rate schedule in Deltek Costpoint, Unanet or a similar system typically pulls this output directly into whatever system already holds the rest of the cost records — the allocation step becomes the reliable feed that system was previously missing, rather than a parallel process run alongside it.
For teams building this into a recurring internal workflow, the API exposes the same allocation programmatically, so a scheduled job can pull newly processed invoices and payroll registers into an internal system automatically rather than requiring someone to export and re-import a file by hand each period.