.png)
Your VP of Engineering emails during close week because $47,000 in facilities costs just landed on her department's numbers, and she wants to know why.
The answer lives in a workbook on someone's laptop, where tab one holds the trial balance export, tab two holds headcount pulled from the HRIS three weeks ago, and tab three holds square footage numbers someone got from the office manager back in 2024. The formula that produced $47,000 spans four cells across two tabs, and the person who built it left in March.
You know the number is right, but you can't show your work in under an hour.
This happens because general ledgers store amounts organized by account and nothing about the operational context that determines how those amounts should be split. The math ends up in a spreadsheet outside the ledger, and the result comes back as a journal entry that strips out how it was calculated. No amount of process discipline fixes that, because the problem is where the work happens rather than how carefully you do it.
Expense allocation distributes shared, indirect costs to the departments, products, projects, or customers that benefit from them. The work breaks into three parts, namely the costs you spread, the drivers you spread them by, and the monthly process that does the spreading.
Most companies allocate from four or five cost pools, starting with facilities and occupancy for rent, utilities, and building services, and IT and software for infrastructure, licenses, and support. HR and people operations covers benefits administration, recruiting, and training, while finance and shared services covers accounting, legal, and procurement. Corporate overhead catches whatever is left, from executive compensation to insurance to anything else that serves the whole company rather than any part of it.
Costs you don't allocate don't disappear, they just sit in an undifferentiated corporate bucket. This means every departmental and product-level P&L you produce is missing part of its true cost.
A driver is a measurable proxy for benefit received. The right driver is the one that tracks how consumption actually varies across recipients.
The catch is that every one of those drivers lives outside your general ledger. Headcount sits in the HRIS, ticket volume in the ITSM tool, and square footage in a facilities system or a spreadsheet the office manager keeps. Your GL holds the costs and none of the information needed to split them, so every allocation starts by assembling data from systems that close on their own schedules.
Cloud and AI spend makes that harder. It's the fastest-growing shared cost at most SaaS companies and the hardest to attribute, and the FinOps Foundation's State of FinOps 2026 report found allocation to be the top priority capability across SaaS, licensing, and data center spend, with attributing AI costs to business units among the hardest problems practitioners report.
The monthly workflow is consistent across most teams:
Step 4 is the one to pay attention to. The calculation happens outside the ledger, using data the ledger never holds, and only the final answer comes back. That's the seam where later questions about the number tend to originate.
Master the month-end close with best practices
Without allocation, shared costs hide in corporate overhead and every department, product, and customer P&L understates what it costs to run. That gap costs you in four ways:
Most teams use one of three approaches, and each breaks down at a different point.
Spreadsheets are the default for good reasons. They model any structure, cost nothing, and every accountant already knows how to use them.
The problem is that they sit outside the ledger. Because the calculation lives in a workbook separate from the system of record, the GL receives the output and nothing else, meaning none of the logic, none of the driver data, and no link back to the source transactions.
That separation produces a predictable set of failures:
The output of that model is a journal entry that debits receiving cost centers and credits the overhead pool. It ties out, it posts cleanly, and it satisfies the ledger.
It's also opaque by design, because while the GL now knows $47,000 went to Engineering, it has no record of which invoices made up the pool, which square footage figures were used, or which version of the model produced the ratio.
That opacity breaks two things downstream:
ERP segments, class tracking, and custom fields are a real improvement over a flat chart of accounts. Tag a transaction with a department at entry and direct costs land where they belong automatically.
Tagging hits its ceiling on shared costs, because it can only describe a transaction as one thing, and a rent invoice benefiting three departments is several things at once. Most systems won't let you tag it 40% Engineering, 35% Sales, and 25% G&A at the point of entry, so the allocation math still has to happen somewhere else.
ERP allocation modules go further and automate the calculation, which is a genuine step up from a workbook. Most still post the result as the same aggregate entry, which means the traceability problem survives the automation.
What's happening above comes down to one thing. A general ledger stores monetary balances by account. It doesn't hold the operational detail that determines how those amounts should be split, things like headcount, square footage, or usage.
That context lives in other systems, so the logic gets rebuilt outside the ledger every period. The GL records shared costs without context, trial balances and driver data get exported to a spreadsheet, and the results post back as aggregate entries that strip out the calculation on the way in. The ledger ends up holding allocated amounts nobody can trace, and next month the cycle runs again.
Because the logic, the data, and the output all sit apart from each other, any change means retracing the whole chain by hand. A reorg is the worst version, since preserving comparability means restating historical allocations one period at a time.
Critically, none of this scales well. Three cost pools across four departments on a single driver is a spreadsheet you can maintain. A dozen pools across departments, product lines, customer segments, and geographies is not, because every new dimension multiplies the combinations instead of adding to them.
Gartner found that most CFOs are still early in adopting AI-enabled cloud ERP, held back by data quality and integration complexity rather than by the software itself. Allocation runs into the same wall, since better tools sitting on a ledger that doesn't hold the context won't fix what's underneath.
Numeric's view is that allocation should run as governed rules inside the accounting system rather than as a downstream spreadsheet posted back as an opaque entry. In practice that means:
All of that depends on the ledger keeping transaction-level context in the first place, which is where most teams are actually stuck. Numeric pulls every transaction line from the ERP with its dimensional detail intact, so reports slice by department, class, location, or entity without ERP administration rights.
It's the same foundation behind continuous accounting, and the reason variance analysis gets easier when every number traces back to the transactions underneath it.

None of this requires buying anything. You can measure what your current allocation setup costs, find where it breaks, and build the case to change it using what you already have.
Get specific about what allocation costs you today.
Then check whether your systems make that manual work unavoidable.
Put a number on what allocation costs today, then frame the upside in terms a CFO acts on.
Expense allocation is technically demanding work, since choosing drivers requires judgment, methodology requires consistency, and both require documentation. None of that goes away with better tooling, and none of it should.
What can go away is the monthly reconstruction around it: the export, the manual driver pull, the model rebuilt by hand each period, and the entry that lands in the ledger without the context behind it. That work exists because the GL doesn't hold what allocation needs, so the math happens in a spreadsheet and comes back as a number that's hard to trace back to its source.
Controllers who separate the accounting judgment from the monthly reconstruction around it evaluate tooling differently, weighing whether a platform's reports trace straight back to the transactions behind them. Numeric's do, and you're welcome to schedule a demo and check for yourself. They end up delivering allocated numbers that already carry their own proof. That shift, from defending the number to discussing what it means, is a large part of what moves accounting into the role of a strategic partner.