ANEK table — ANEK Asset Accounting Document Header

One row in ANEK represents the header of a single document created inside Asset Accounting - not the individual asset movement itself. Whenever a transaction posts to one or more fixed assets (an acquisition, a retirement, an intercompany transfer, a depreciation run for a period, a manual value correction), the system writes one ANEK header for that document within a company code and fiscal year. The header carries posting metadata: dates, user, transaction code, business transaction type, currency, and a reversal flag. It deliberately does not carry the asset number, the transaction type per asset, or any amount - those belong to the associated rows in ANEP, sometimes several ANEP rows per single ANEK header when one document affects multiple assets, such as a depreciation posting run.

Always restrict on MANDT and BUKRS before anything else; ANEK spans every company code and every fiscal year Asset Accounting has ever posted in, and it grows with every depreciation run, so an unrestricted select is expensive. GJAHR is the second mandatory filter for any reasonable selectivity. LNRAN is not a date-ordered or globally unique key, so do not use range selection on it expecting chronological order across company codes or years; use BUDAT or BLDAT for date filtering instead. Because ANEK carries no asset number, any selection intended to find postings against a specific asset has to start from ANEP or ANLA and join back to ANEK, not the other way around.

Symptom: an asset acquisition was posted but does not show up in the depreciation forecast for the period. Selection: query BKPF for the FI document number and company code to get GJAHR and BELNR, then select ANEK on BUKRS, GJAHR and BELNR to find the matching LNRAN, then select ANEP on that BUKRS, GJAHR, LNRAN to see the actual asset (ANLN1/ANLN2) and transaction type posted, and check XSTOV on the ANEK row to confirm the document was never reversed.

ANEK continues to exist in S/4HANA and is still populated when classic Asset Accounting postings occur, largely for backward compatibility with reports and interfaces built against it. The authoritative record of the posting, including amounts and the full universal journal view, sits in ACDOCA, which carries the asset dimension fields directly on the journal entry line. New reporting and analytics work is generally built against ACDOCA or its CDS views rather than against ANEK and ANEP directly, though the classic tables remain usable for existing custom reports.

A data question on ANEK belongs to whoever owns Asset Accounting configuration and postings on the project, typically the FI-AA lead, not the general ledger or accounts payable team. Discrepancies between asset postings and the general ledger usually require someone who also understands the depreciation area and transaction type setup, since the header alone cannot explain a wrong amount or a missing line.

ANEP holds the per-asset line items belonging to each ANEK header and is the table to join to for the actual asset and transaction type. ANLA and ANLC provide the asset master record and its annual value totals. BKPF is the general accounting document header linked through BELNR, BUKRS and GJAHR. Depreciation posting runs and manual asset postings (acquisitions, retirements, transfers) are the transactions that write new rows into ANEK and ANEP together.