Asset Acquisition Posts to Wrong Asset Class Account
The acquisition document is picking up the wrong balance sheet account because the asset master is assigned to the wrong asset class, or the account determination key on the correct class is mapped to the wrong general ledger account in the chart of accounts. Check the asset master's class first, then the account determination configuration, before assuming it is a posting error.
Covers the common reasons an asset acquisition (via F-90, MIGO/MIRO with account assignment category A, or an asset transfer) lands in an unexpected general ledger account instead of the one expected for its asset class. Focuses on the interaction between asset class, account determination key, and chart of depreciation account assignment, since that chain is where almost every case of this issue traces back to.
Published 16 Sept 2026· 1,169 words
The business symptom
Fixed assets accounting or the plant controller notices that a newly capitalized asset, or a batch of assets from a recent purchase, has landed under the wrong balance sheet line in the trial balance. Machinery shows up under IT equipment, or a leasehold improvement posts to the general building account instead of the leasehold improvements account. Sometimes it surfaces when the depreciation run produces an unexpected posting, or when the asset history sheet is reconciled against the general ledger and a variance appears that nobody can explain from the document itself, since the FI document looks perfectly normal and balanced.
The configuration behind it
- Asset master created under the wrong asset class. The class was copied from a similar existing asset or picked from a dropdown without checking, and the class itself is not the problem, the assignment on that specific asset is.
- Account determination key on the asset class points to the wrong general ledger account for the acquisition posting in the relevant chart of accounts. This is a configuration issue shared by every asset in that class, so if one asset is wrong under this cause, all assets in the class in that company code are wrong.
- The account determination key is correct but has not been maintained for the chart of accounts used by the company code posting the acquisition, so the system falls back to a default or errors are masked by a substitution.
- Transaction type used for the acquisition (external acquisition versus sub-number acquisition versus transfer) is mapped to a different account assignment than expected, so the same asset posts correctly on one movement type and incorrectly on another.
- MM-integrated acquisitions (goods receipt or invoice receipt against a purchase order with an asset account assignment category) inherit the account determination from the asset number entered on the purchase order line, not from the invoice, so the wrong asset number on the PO produces the wrong account with no error at MIRO.
- A validation or substitution rule active on the company code rewrites the account or cost element during posting and was set up for an unrelated purpose, then starts catching asset postings it was never meant to touch.
- Asset class was set up as a copy of an existing class for a new asset category, and the account determination key was left pointing at the source class instead of being redirected to the new key.
What to check
Start with the asset master (AS03) and confirm the asset class and the account determination key derived on it. Then check the account determination assignment for that key in the asset accounting configuration against the chart of accounts (this is IMG configuration, not a transaction most functional users run directly, so pull it via the asset accounting customizing node rather than guessing the account from memory). Display the posted document (FB03) and note the actual G/L account, transaction type, and asset number used. If the acquisition came through procurement, check the purchase order account assignment tab (ME23N) for the asset number and sub-number entered there. Finally check for active validations or substitutions on the company code (GGB0) that reference asset G/L accounts or asset classes.
- AS03 - confirm asset class and account determination key on the asset master
- Asset accounting IMG - account determination to chart of accounts assignment for that key
- FB03 - review the posted document, transaction type, and account actually hit
- ME23N - for MM-integrated acquisitions, check asset number and sub-number on the PO line
- GGB0 - check for validations or substitutions active on the company code
How to prove it in the data
Pull the asset history sheet for the asset class in question alongside a general ledger account balance display for the account actually posted to, for the same company code and posting period, and compare against the account determination key's expected G/L account from configuration. A mismatch between the account determination key's configured target and the account on the posted document, for an asset confirmed to be in that class, is the proof; a mismatch between the asset's actual class and its expected class points instead to a master data error upstream.
Resolution path
If the asset master is simply in the wrong class, this is master data, not configuration: the asset needs to be moved to the correct class, typically using an intercompany or intracompany asset transfer transaction rather than a manual reclassification journal entry, so that depreciation history and APC values move with it. If the account determination key on the class points to the wrong general ledger account, that is configuration and requires a transport through the change management landscape, and any postings already made under the wrong account need a manual correcting journal entry once the configuration is fixed, since correcting configuration does not retroactively repost history. If the cause is a validation or substitution rewriting the account, the fix is a change to that rule, also a transport. If the cause is a wrong asset number on a purchase order, the open PO line needs correction before the next goods receipt or invoice, and anything already posted needs a transfer, not a PO change, since PO changes do not touch documents already posted.
The fix people try first (and why it fails)
The reflex fix is to post a manual journal entry moving the value from the wrong account to the right one in the general ledger, without touching the asset itself. This clears the trial balance symptom for that period but leaves the asset master pointing at the wrong class, so the asset history sheet, depreciation run, and any future acquisition on that same asset keep posting to the wrong account. It also breaks reconciliation between the asset subledger and the general ledger, since the manual entry has no asset transaction behind it, and it has to be repeated every period until someone fixes the actual class assignment or account determination.
Whose problem this is
Asset accounting configuration and the account determination key mapping belong to the FI-AA functional consultant or the fixed assets configuration owner. Asset master data corrections, including class transfers, are usually a fixed assets accounting team responsibility. The handover note should state the asset number, the class it was in versus the class it should be in, the account determination key involved, whether a transport is needed or just a master data transfer, and which periods already have postings requiring manual correction.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-functional-issues/asset-acquisition-not-posting-to-the-correct-asset-class-accountERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.