SAP tableObjectANLAModuleFI_FICO

ANLA table — Asset Master General Data Table

ANLA is the fixed asset master table in Asset Accounting. One row identifies a single asset or asset sub-number within a company code and holds asset class, capitalization date, deactivation date, description texts and the deletion flag. It carries no monetary values; those live in ANLC, and transaction history lives in ANEK and ANEP.

This page covers what ANLA stores, its key fields, and how it joins to value and transaction tables in FI-AA. It focuses on the diagnostic reads consultants actually run against it - proving whether an asset is deactivated, deleted, or simply missing from a company code - and the wrong conclusions that get drawn from a blank or populated field.

Published 15 Sept 2026· 1,037 words

What it stores

One row represents the master record of a single fixed asset, or asset sub-number, within a company code: the combination of company code, main asset number and sub-number identifies exactly one row. ANLA holds data that does not vary by fiscal year or period - asset class, capitalization date, deactivation date, description texts, and the deletion flag. It is the anchor record for everything else in Asset Accounting: no value posting, no depreciation calculation, and no transaction line item exists without a corresponding ANLA row already in place. The table does not hold monetary values or depreciation terms; those live elsewhere. Every asset, whether currently in use, fully depreciated, or scrapped years ago, still has exactly one row here unless it has been physically removed by archiving.

Key fields

  • MANDT - client
  • BUKRS - company code that owns the asset
  • ANLN1 - main asset number
  • ANLN2 - asset sub-number, used for components or additions to the main asset
  • ANLKL - asset class, drives depreciation area defaults and GL account determination
  • AKTIV - capitalization (activation) date, when the asset entered productive use
  • DEAKT - deactivation date, populated when the asset is retired or scrapped
  • TXT50 - asset description, short text
  • TXA50 - asset description, second text line
  • LOEVM - deletion flag, set when the asset is marked for deletion or archiving

How it joins the data model

  • ANLA-BUKRS = ANLC-BUKRS and ANLA-ANLN1 = ANLC-ANLN1 and ANLA-ANLN2 = ANLC-ANLN2, joining the master to the year-dependent value table
  • ANLA-BUKRS = ANEK-BUKRS and ANLA-ANLN1 = ANEK-ANLN1 and ANLA-ANLN2 = ANEK-ANLN2, joining to the transaction header for postings on that asset
  • ANEK-BUKRS = ANEP-BUKRS and ANEK-ANLN1 = ANEP-ANLN1 and ANEK-ANLN2 = ANEP-ANLN2, chaining down to the individual transaction line item
  • ANLA-BUKRS = BSEG-BUKRS and ANLA-ANLN1 = BSEG-ANLN1 and ANLA-ANLN2 = BSEG-ANLN2, linking to the FI document line that posted the acquisition, transfer or retirement

How to read it safely

ANLA is client-dependent; every selection needs MANDT and BUKRS. Restrict on BUKRS first, then narrow by ANLN1 range or ANLKL - row counts per company code are modest, so a targeted range read is fast without a custom index. Wildcard searches on TXT50 are expensive and should be a last resort. Do not select on DEAKT alone to find retired assets across company codes; scope to BUKRS first. When joining to value or transaction tables, always carry BUKRS, ANLN1 and ANLN2 together - ANLN1 alone repeats across company codes and returns unrelated assets.

How to prove it in the data

Symptom: an asset stopped appearing in the current depreciation run. Select single from ANLA where BUKRS equals the company code and ANLN1 and ANLN2 equal the asset number, and look at DEAKT. If DEAKT contains a date on or before the run's period end, the asset was deactivated and depreciation correctly stopped - not a program error. If DEAKT is blank, the exclusion is coming from depreciation area configuration or a lock at the asset time-dependent or depreciation-area level, not from ANLA.

ECC vs S/4HANA

ANLA still exists as a transparent table in S/4HANA and remains the master record for Asset Accounting; it has not been replaced by a compatibility view. What changed is where the values sit - under the universal journal, actual postings flow into the universal journal table, and ANLC is retained as a compatibility or summary table rather than the sole source of truth for values. Master data behaviour, field content and the primary key of ANLA are unchanged from ECC to S/4HANA.

Common pitfalls

  • Treating a blank DEAKT as proof the asset is still fully active - a shortened useful life or a partial retirement can already exclude it from a specific depreciation area without touching DEAKT.
  • Assuming ANLA carries the asset's book value or net book value - it does not; APC and accumulated depreciation live in ANLC and are built from ANEP/ANEK postings, not stored redundantly in ANLA.
  • Reading ANLKL as history - ANLA shows only the current class; a class change overwrites the field, so postings made under the previous class are not visible here.
  • Forgetting ANLN2 - filtering only on ANLN1 silently drops sub-numbers, understating asset counts and hiding components that were retired independently of the main asset.
  • Assuming LOEVM equal to X means the row is gone - it means the asset is flagged for deletion in the next archiving run; it can still be selected and will still appear in reports until archiving actually executes.
  • Assuming a missing ANLA row means the asset was deleted - more often it means the asset was never created in that company code, or the number entered belongs to a different company code entirely.
  • Reflex fix of recreating a 'missing' asset master through the asset creation transaction instead of checking whether it exists under a different company code or is simply blocked - this creates a duplicate with a new internal key and breaks the link to existing ANLC and ANEP history.

Whose problem this is

The FI-AA configuration owner or asset accounting process lead owns questions about ANLA content - asset class assignment, capitalization and deactivation dates, and deletion flags. Basis is only involved for archiving runs that physically remove flagged rows. Data corrections go through the standard asset master transactions, never through direct table maintenance.

Related SAP objects

Reviewed pages this object connects to in the ERPClimb knowledge graph.

Source: ERPClimb — https://erpclimb.com/sap-tables/anlaERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.