Skip to main content
Help Center

Two views, one result: the core principle of cost accounting

Why every posting carries a cost centre and a cost object, why both totals must always show the true result and why cross-postings from a cost centre to a cost object count twice.

The most important principle of cost accounting in teamspace is: total of all cost centres = total of all cost objects = true result. Every posting carries a cost centre and a cost object. This gives two complete views of the same euros: the department sees all its costs, the project sees all of its own. After every posting, reposting and allocation, both views must show the same result. If one differs, something has been counted twice or is missing.

Example: four postings, two views

PostingCost centreCost objectAmount
B1 LicenceKS1KT1−€1,000
B2 TravelKS1KT2−€400
B3 RentKS2KT2−€2,000
B4 RevenueKS2KT1+€2,000
True result−€1,400
  • Cost centre view: KS1 −€1,400, KS2 €0 → total −€1,400 ✓
  • Cost object view: KT1 +€1,000, KT2 −€2,400 → total −€1,400 ✓

The same four postings, grouped twice, give the same result twice. That is how it should stay.

Three rules that follow from this

  1. Each view is complete. The department sees all its costs, the project sees all of its own. Overheads such as rent are therefore posted to an internal cost object so that the cost object view stays complete too.
  2. Movements stay within their view. Repostings and allocations go from cost centre to cost centre or from cost object to cost object.
  3. The only exception is the salary cost centre. It only holds salaries without a cost object. That is why it may distribute to cost objects via time bookings and allocation without anything arriving twice.
Cost centre view IT Service cost centre Consulting Final cost centre Salary CC Consulting hidden, not counted Allocation ✓ Cost object view SRV pool Intermediate cost object P-2026-018 Final cost object P-2026-021 Final cost object Allocation ✓ ✗ Cross-posting counts twice ✓ Time booking + rest the only bridge
Movements stay within their view. Only the salary cost centre may distribute to cost objects.

Why cross-postings count twice

A posting from a normal cost centre to a cost object switches the view. It takes the amount out of the cost centre view and puts it into the cost object view. This always goes wrong, because the amount has usually already arrived there.

Server example: The data centre (CC 5100) has €3,600 in server costs. If you posted them directly to the maintenance contracts:

CC 5100Σ cost centresΣ cost objects
before−3,600−3,6000
after00 ✗−3,600

The data centre loses its costs. And where the amounts were already attached to a cost object, they arrive there a second time:

Cross-posting in the testΣ cost objectsTrue result
Reposting KS2 → KT2, €200−€1,600−€1,400
Allocation KS2 → KT1/KT2, €1,200−€2,800−€1,400

For every genuine use case there is a route that respects the principle. For the servers, that is an intermediate cost object acting as a pool, which an allocation distributes to the contracts. The data centre keeps all its costs (see Set up an allocation rule).

The “Cross-posting” switch

A switch in the configuration controls whether cross-postings from a normal cost centre to a cost object are possible:

Configuration → Finance → Settings → Cost accounting → Cross-posting (cost centre/cost object)
  • Off (recommended): repostings and allocations stay within their view. Only salary cost centres may post to cost objects.
  • On: normal cost centres may also repost and allocate to cost objects. This lets you break the principle.

The switch has no effect on salary cost centres. They may always distribute to cost objects, because they only hold salaries without a cost object – so nothing can arrive twice.

Permitted routes at a glance

RouteAllowedUse case
Reposting cost centre → cost centre✓reclassification, margin share for the department doing the work
Reposting cost object → cost object✓splitting a trip between two customers
Allocation service cost centre → cost centres✓IT, administration, management
Allocation intermediate cost object → cost objects✓servers, licences, pools
Time booking and allocation salary cost centre → cost objects✓salary and remainder
Reposting or allocation normal cost centre → cost objectonly with the “Cross-posting” switchno use case

How this compares: DATEV, Business Central and SAP

Two complete evaluation views are the principle behind DATEV KOST1/KOST2 and the dimensions in Microsoft Dynamics 365 Business Central. SAP CO works differently: there, each euro sits in exactly one place and moves from the cost centre to the cost object through settlement. Both approaches are correct. teamspace uses complete views so that every department and every project can see its costs in full at any time.

Anyone coming from the SAP world often looks for the “cost centre → order” settlement. In teamspace, it deliberately exists only via the salary cost centre. In SAP, this corresponds to activity allocation with actual price revaluation.

Common problems

The totals of the two views differ. There is almost always a cross-posting behind it: a reposting or allocation from a normal cost centre to a cost object. Check the movements of the cost centres involved to see whether one counterpart is a cost object, and whether the “Cross-posting” switch is on. A second cause: a posting has only a cost centre but no cost object (or vice versa). The exception is the salary on the department, whose cost object side is created via the salary cost centre.

I cannot select a cost object as the target of a reposting. That is correct if the source is a normal cost centre and the “Cross-posting” switch is off. The target always has the same type as the source.

The cost centre total includes the salary cost centre. Salary cost centres are hidden and are not counted in any total. However, if a salary cost centre sits under the department in the cost centre tree, the node adds up its relief as well. Place it outside the department node.