A general ledger can tell you exactly how much overhead a company spent last month. It cannot tell you which product, customer, or service actually earned that overhead, or whether the margin reported on paper survives once indirect costs are attributed honestly.
D365 cost accounting exists to close that gap. It sits alongside the general ledger and reallocates the same posted dollar using allocation bases such as machine hours, square footage, or headcount, not a flat percentage, until that cost lands where it was actually consumed. This guide will explore how D365 cost accounting turns raw ledger cost into allocated cost, cost object by cost object, and where that process actually earns true margin visibility.
What feeds D365 cost accounting before any allocation happens
Cost accounting runs as its own module, distinct from the general ledger, though it is usually built on a Cost Accounting Ledger shared from it. Nothing gets allocated until source data actually lands inside that ledger, and D365 cost accounting pulls from more places than most finance teams expect:
- General ledger balances, brought in by cost element, the cost accounting equivalent of a main account.
- Sub-ledger detail and budget figures, so planned cost can sit next to actual cost inside the same structure.
- Statistical dimensions, non-financial data such as machine hours, kilowatt hours, headcount, or square footage, that has no place in the general ledger but is exactly what overhead allocation needs to be accurate.
None of this arrives allocated. It arrives as raw cost sitting against a cost center or a main account, waiting for a rule to decide where it actually belongs.
A payroll feed is a useful example of why this matters. Salaries post to the general ledger as a single primary cost element, correctly, from a general ledger perspective, since payroll does not care which product an employee happened to spend the week supporting. Cost accounting is what takes that same salary figure and, using a statistical dimension such as hours logged per project or per product line, works out how much of it each cost object should actually carry. The general ledger entry never changes. What changes is everything built on top of it once cost accounting gets involved.
Cost elements, cost centers, and cost objects: the three things allocation runs on
Cost elements: primary and secondary
A primary cost element mirrors a general ledger main account, salaries, rent, utilities, brought in largely unchanged. A secondary cost element exists only inside cost accounting, created specifically to move a balance from one cost center to another during overhead calculation without ever touching the general ledger itself.
Cost centers: where overhead first lands
Cost centers represent departments or business units, the first stop for most overhead before it goes anywhere else. An IT department’s expenses, for example, sit in a cost center until an allocation rule decides how much of that cost each consuming department should carry.
Cost objects: where overhead is ultimately consumed
Cost objects are the products, services, or projects a business actually sells. Overhead allocation exists to answer one question for each of them: after every indirect cost is fairly attributed, what does this cost object actually cost to deliver, and against what does its true margin visibility need to be measured?
D365 cost accounting treats this as a hierarchy rather than a flat list. A cost object dimension hierarchy can group individual products up into product lines, and product lines up into a whole business unit, so a rule written once at the right level of that hierarchy applies consistently down through everything beneath it, instead of needing a separate rule maintained for every single product.
Mapping cost elements, cost centers, and cost objects correctly is most of the work. Seeing the result laid out by product or customer is where the Metrixs analytics suite picks up.
How overhead allocation actually happens: bases, rules, and policies
Cost accounting supports three types of allocation bases, the basis on which overhead cost gets split across cost objects: a fixed quantity, a statistical dimension such as machine hours or headcount, or a formula built from other cost elements. Getting the allocation base wrong is usually where the whole exercise quietly stops reflecting reality, even when every dollar still technically balances.
- Cost allocation policies and rules define how allocation actually runs, assigned to a cost control unit, and every rule is date-effective, so it can be expired and replaced with a newer version without losing the history of what applied when.
- A cost rollup policy uses secondary cost elements to move balances between cost centers before the cost ever reaches a cost object, which is what lets an organization trace exactly how overhead flowed on its way to a product rather than seeing only the final allocated number.
- Overhead calculation runs as a defined set of steps, cost behavior classification, cost distribution, and cost allocation, and it can be rerun for the same fiscal period if source data was missing or a rule needed correcting.
One consequence of this design is easy to miss during setup. Once overhead calculation completes, an auxiliary cost object ends up with a zero balance for the primary cost element it received, since the whole point was to move that cost onto the object rather than leave it sitting where it started. Organizations that expect to trace the original salary or rent line all the way through to a specific product usually need secondary cost elements set up deliberately for that, rather than assuming the primary allocation alone will show the full path cost took to get there.
If overhead allocation rules have drifted from how the business actually consumes shared cost, a Metrixs consultant can help re-map allocation bases against current reality.
The Cost control workspace: where allocated cost becomes visible
The Cost control workspace is where allocated cost actually gets reviewed. Cost accountants can build custom report layouts, filter the underlying data foundation for each report, and drill into an individual cost entry to see exactly which allocation base and formula produced a given number.
- Reports can be shared across the team or kept internal to cost accountants, so a rough working report and a polished one meant for wider circulation do not have to be the same thing.
- Because overhead calculation can run more than once per fiscal period, the workspace always reflects the most recent calculation, not a stale first pass.
This is a genuinely capable native tool, not a bare-bones summary screen. What it does not do on its own is hold several fiscal years of allocated cost side by side, or combine cost object margin with the general ledger, budget, and fixed asset data those same cost objects also touch. Each of those lives in its own reporting space, so a single, true margin view across all of them still means pulling from more than one place, which is usually the point where D365 cost accounting starts to feel like several separate tools rather than one connected picture.
| What you need | Native D365 F&O tools | A dedicated layer such as Metrixs |
|---|---|---|
| Multi-year allocated cost trend | One fiscal period’s calculation at a time | Configurable history in one saved view |
| Margin next to GL, budget, and assets | Separate modules, separate reports | One reporting layer across all of them |
| Cross-entity cost object comparison | Assembled by hand, entity by entity | Consolidated across entities automatically |
| Refresh | Whatever the last overhead calculation produced | 15 to 30 minutes via Synapse Link |
From allocated cost to true margin visibility
Margin visibility is the point of the entire exercise, not an extra step tacked onto the end of it. Once overhead allocation has finished moving cost through cost centers and onto cost objects, every product, service, or project carries a cost figure that actually reflects what it consumed, not a rough share of total overhead divided evenly across everything the business sells.
- A product that looked profitable under a flat overhead allocation can turn out to be marginal, or worse, once machine hours or floor space are allocated based on what it actually used.
- A product that looked like a low performer under the old allocation can turn out to be one of the more efficient users of shared resources, once the allocation base reflects that.
Neither outcome is visible from the general ledger alone. Both are exactly what D365 cost accounting is built to surface, provided the allocation bases and rules behind it are actually kept current.
How Metrixs extends D365 cost accounting into one margin view
Metrixs reads cost entries, allocation results, and cost object balances through Azure Synapse Link into the same dedicated Azure Data Lake used for the rest of D365 F&O, built across more than 6,000 backend tables.
- Allocated cost and margin held as configurable history, so a multi-year view of a cost object’s true margin is a saved report, not a re-run calculation.
- Cost object margin shown next to general ledger, budget, and fixed asset data, even across a multi-entity or multi-ERP environment, instead of pulled from separate modules by hand.
- Refresh every 15 to 30 minutes, inside the same 12-module, 100+ report, 1,000+ metric suite, most deployments live in under 6 weeks, client ROI 290% to 450%.
For an organization already running D365 cost accounting to allocate overhead correctly, this is the difference between reviewing margin once a period closes and watching it move in something closer to real time.
Curious what cost object margin looks like sitting next to the rest of your financial reporting? See the D365 F&O finance and accounting analytics use case.
Frequently asked questions
What is D365 cost accounting used for?
D365 cost accounting allocates indirect and overhead cost across cost centers and cost objects, products, services, or projects, so a business can see the true cost, and true margin, of what it actually sells. It runs alongside the general ledger, pulling in financial, budget, and non-financial statistical data to build allocation rules on.
What is the difference between a cost center and a cost object?
A cost center is usually a department or business unit, the first place overhead cost lands before allocation. A cost object is a product, service, or project, the point where cost is meant to end up so its true margin can be measured. Overhead allocation is the process that moves cost from centers to objects.
How does cost allocation work in D365 F&O?
Cost allocation runs on allocation bases, a fixed quantity, a statistical dimension such as machine hours, or a formula, defined inside cost allocation policies and rules. Overhead calculation applies those rules through the same three steps covered above, and the whole calculation can be rerun within the same fiscal period if source data changes or a rule needs correcting.
What is overhead allocation in D365 cost accounting?
Overhead allocation is the process of moving indirect cost, rent, utilities, shared department expense, from where it was originally posted to the cost objects that actually consumed it. It typically uses secondary cost elements and a cost rollup policy to pass balances between cost centers before the cost reaches a cost object.
What does the Cost control workspace show?
The Cost control workspace shows allocated cost entries for a given fiscal period, with custom report layouts, drill-down into the allocation base behind any number, and the ability to share a report or keep it internal to cost accountants. It reflects whichever overhead calculation ran most recently for that period.
How is margin visibility different from a standard profit and loss report?
A standard profit and loss report typically shows overhead as one lump figure, or splits it evenly regardless of actual consumption. Margin visibility from cost accounting reflects overhead allocated by actual usage, machine hours, headcount, square footage, so two products with identical revenue can show meaningfully different true margins once allocation is applied.
Can D365 cost accounting compare margin across legal entities?
Not natively as a single consolidated view. Each Cost Accounting Ledger and its Cost control workspace reporting reflect their own scope, so comparing cost object margin across legal entities, or holding several years of allocated cost side by side, usually means exporting from each entity and combining the results by hand.
The verdict
D365 cost accounting is a genuinely capable module on its own: real allocation bases, real cost rollup logic, and a Cost control workspace built specifically for reviewing the result. Cost allocation done well is what turns a flat, evenly-spread overhead number into something that actually reflects how a business consumes its own shared resources.
Where it stops is holding that margin as history, and showing it next to the rest of financial reporting across entities. Metrixs closes that gap: reading the same cost entries and allocation results, refreshing every 15 to 30 minutes, and shipping true margin visibility as part of the same suite that already covers general ledger, budgeting, and fixed assets.
Ready to see your own cost objects’ true margin as one connected view? Book a Metrixs reporting assessment, and we will map your cost elements and allocation rules against what the reporting layer already covers.
