A machine, a down payment and two costs in the wrong account

Capitalise (APC):

• Machine, net: 240,000
• Freight (directly attributable to bringing the asset to its location): 15,000
• Installation (directly attributable to bringing it to working condition): 12,000
• Total APC EUR 267,000
• Input tax is not capitalised - it is deductible and recovered; posting it to APC would overstate the asset and the depreciation.

Down payment. The EUR 30,000 is not an additional cost; it is a payment on account. It must be transferred/cleared to the asset so the advance account nets to zero - otherwise the same machine appears once as an advance and once as an asset, and depreciation is computed on an incomplete base. If the advance is never transferred, it sits as an asset under construction with no depreciation, and the balance sheet shows both.

Depreciation start date. The depreciation start date is derived from the capitalization date, not from the invoice date and not from the commission date by default. With capitalization date 1 April 2024, the first depreciation period is April, and pro-rata monthly depreciation for 2024 is 9 months: 267,000 / 120 = 2,225 per month → 20,025 for 2024.

If the acquisition had been posted with asset value date 18 March, depreciation would start in March and you would depreciate 10 months - one month too many, overstating 2024 depreciation by 2,225.

Correction route. Do not simply book a debit to the asset against the expense account in the current period. Use a post-capitalization / acquisition-from-expense transaction with automatic offsetting entry: debit asset, credit the original expense account. This keeps the audit trail (original invoice → correction → asset) intact, which a manual journal does not.

Asset value date is the critical field. Set it to 1 April 2024, the original capitalization date, so the system treats the cost as having been incurred from the start of use and calculates catch-up depreciation from April.

Effect on 2024:

• Correct APC: 267,000 → 2,225/month → 20,025 for April–December.
• If the corrections carry the posting dates (5 April and 20 April), depreciation starts in April and May respectively and the catch-up is short by roughly one month per correction.
• If the corrections were made after the April depreciation run, the system posts the difference in the period in which the correction is made (unplanned/catch-up), so the annual total is right but the monthly P&L is distorted. Note it or reverse and re-run April.

Also check area 15. After APC changes, verify that the derived tax area picked up the new base and that its 7-year useful life still applies: 267,000 / 84 = 3,178.57 per month.

The difference. Area 01 is the real, posting depreciation area for the group books - 10-year straight line on EUR 267,000 = 2,225/month, 9 months in 2024 = 20,025. Area 15 is a derived area used for tax, with a 7-year useful life on the same APC: 267,000 / 84 = 3,178.57/month → 9 months = 28,607.14. The 2024 gap is EUR 8,582.14.

What posts. Only posting areas generate FI documents. Area 15 is derived and informational - it does not produce its own accounting document, so the general ledger only ever sees 20,025. The tax difference is documented in the asset reports and, if the group needs it in the books, it belongs in a separate (tax) ledger, not in a second posting area of the same ledger.

Points to verify before answering the auditor:

• Derived areas must be re-derived when the base area or the useful life changes; a manual change to area 15 does not automatically reflow.
• The monthly run must have run for every period in which a posting area has values - a missed period creates a gap that has to be caught up.
• If group policy requires a mid-month or half-year convention, that must sit in the depreciation calculation method of the key; it is not a manual adjustment, and retrofitting it changes every prior calculation.