Year-end valuation of foreign-currency items: one invoice, two years, two results

The Same Invoice, Twice

Yesterday I wrote about exchange differences on payments. Today it's the other half of the problem, the one that lands on 31 December.

A client on full books sells to a German customer. The 50 000 EUR invoice is dated November and booked at the NBP rate from the day before, say 4.3000. That's a receivable of 215 000 zł. By 31 December nobody has paid it. The rates here are round and illustrative, not real ones.

• 31 December, books: art. 30 of the Accounting Act requires the receivable to be revalued at the NBP average rate in force that day, say 4.2500. The receivable drops to 212 500 zł. The books get 2 500 zł of negative exchange difference, a financial cost in the old year.
• 31 December, tax: nothing. Under the default tax method, that difference is unrealised and stays out of the tax base.
• January, payment: the customer pays, the bank converts at its buying rate, say 4.2800. For tax, the realised difference is 50 000 × (4.2800 − 4.3000) = −1 000 zł, a cost in the new year.

One invoice, two years, and the books and the tax return show different numbers in different periods. That's correct.

The trouble starts when nobody keeps track of which number belongs where.

Who This Concerns

Only clients on full books. Clients on KPiR or lump-sum tax don't do balance-sheet valuation, and their exchange differences arise only on payment. In a typical 40-client portfolio that leaves maybe 8 to 12 clients with foreign-currency items. Not many. But they're usually your biggest clients, and the ones with an auditor watching.

What gets revalued: receivables and payables in foreign currency, loans and credit facilities, and cash on currency accounts and in currency cash desks. What usually doesn't: fixed assets and inventory bought in euros, prepaid costs, and advances for deliveries. Advances are the grey area. The common view is that an advance paid for goods isn't a claim to be settled in currency, so it isn't revalued. Even so, agree it with the client's auditor and write the decision down.

Where the Two Methods Split

A client can treat exchange differences for income tax in one of two ways. Before you touch December, you need to know which one each client uses:

• Tax method (default). Valuation differences are left out of the tax base. The tax difference is calculated only when money moves, against the historical booking rate. This is what most clients use.
• Accounting method (art. 9b CIT, art. 14b PIT). Exchange differences are recognised for tax the way they are in the books, valuation included. The sources I checked say it's only available to taxpayers whose financial statements are audited, and that the election binds for at least three tax years. It's reported in the annual return; check the client's file for whether an earlier notification was also made.

Under the accounting method the books and the tax calculation match, and most of what follows doesn't apply. Under the tax method, every revalued item creates a gap that someone has to close twice: once in December and once when the item is paid.

The Three Places It Goes Wrong

1. December: the valuation stays in the tax calculation. The year-end trial balance includes 2 500 zł of valuation cost. If the annual CIT calculation doesn't exclude it, taxable income is understated by that amount. On one invoice that's small. On a client with 150 open items and a weak zloty month, it's an error you'll explain to the auditor or to the tax office.

2. January: no reversal. Many offices reverse the valuation on 1 January, putting every item back at its historical rate. Others don't, and both can be correct for accounting, depending on the client's policy. But without the reversal, the January payment in my example shows +1 500 zł in the books (4.2800 against 4.2500), while the tax difference is −1 000 zł. If the monthly tax advance is calculated from the ledger, it's now wrong by 2 500 zł, in the opposite direction from December.

3. Currency accounts: two queues. The balance-sheet valuation resets the EUR account to the 31 December rate in the books. For tax, the FIFO layers of that account (or whatever method the client agreed with their advisor) continue at their historical rates. After year end you need both: the accounting rate and the tax layers. If you only kept the books, the tax layers have to be reconstructed. That usually happens in March, under pressure.

That's why I'd rather prepare the valuation as a list in December than as a pile of postings on 31 December.

The Year-End List

This is what I'd want on the accountant's desk in the first days of January, per client with foreign-currency items:

• every open foreign-currency item as of 31 December, pulled from the ERP's settlements (I covered where that data sits in enova365 settlements and receivables reporting): document, currency, amount, booking rate;
• the NBP table A rate in force on 31 December, taken from the NBP's public API, not typed in;
• the valuation difference per item and the total, positive and negative;
• currency account and cash desk balances, with the tax FIFO layers carried forward next to the accounting balance;
• flags: advances, items with a currency but no clear monetary nature, items where the booking rate is missing or looks wrong, and items that are already settled in the bank statement but still open in the ledger;
• the client's tax method, from a register, not from memory, and under the tax method the total that has to be excluded from the annual tax calculation.

In January, the same list does a second job: it checks that the reversal was posted (if the client's policy uses one) and keeps the historical rates for every item paid in the new year. That's the input for the January payment differences, the same monthly process I described in yesterday's post.

The flagged lines are where the accountant's time goes. For a client with around 120 open items, building the list by hand takes about two hours, most of it spent looking up rates and balances. With the list already prepared, the review takes about 20 minutes. The year-end valuation also feeds the tax markers on accounts for clients who send JPK_CIT, where unrealised differences have to be kept apart from the realised ones.

The agent doesn't choose the tax method, doesn't decide whether an advance is revalued, and doesn't post the valuation. I explained why I keep that line in AI agents and liability.

Do a Dry Run in November

31 December is the worst possible day to find out what's broken. Run the same list on 30 November for each full-books client with currency items. You'll find the missing booking rates, the advances nobody classified, and the clients whose tax method isn't written down anywhere. And you'll still have a month to fix them. Pair it with the year-end balance confirmations, which go out around the same time and cover the same open items.

If you'd like to see the year-end valuation list built from one of your clients' ERP data, write to me. I'll run it on a real client and tell you honestly whether it's worth automating at your volume.