If your business buys abroad or sells to the EU, foreign currencies live inside your company whether you want them or not. The real question is whether you know how much you're actually making or losing on them — or whether you find out once a year at closing, when nothing can be done about it.
In Polish SMEs the pattern repeats so often you can set your watch by it. The company starts with occasional purchases from China or one or two German customers. For the first year everything flows through the bank, the accountant does the conversions, "the rate will average out somehow". Then volume grows, a second counterparty appears, a third currency account. The ERP — Comarch Optima, Microsoft Dynamics AX, enova365, Subiekt — was configured in PLN because that's how it was rolled out. Foreign-currency invoices get keyed in by hand, FX rates get keyed in by hand, FX differences are calculated once a quarter, usually after the deadline. The real margin on foreign-currency contracts is something nobody actually knows — it lives in the owner's head as a feeling that "this year was tougher".
AI, dashboards and every buzzword du jour won't help you here as long as underneath it there's still an Excel with FX rates copied off the internet.
Why FX hurts more than it seems
The problem with FX in SMEs isn't that "the rate moves". Everybody knows that. The problem is that in the life of a single foreign-currency transaction there are three, sometimes four different rates, and each one books into a different place.
- The rate on the day of the order (that's what your quote margin was built on).
- The rate on the invoice date (that's what VAT, tax and JPK run off).
- The rate on the payment date (that's what the bank settles against).
- The National Bank average from the previous day — because the law wants its own.
The gaps between these aren't "a few groszy" in practice. With EUR/PLN and a typical 60-day order-to-pay cycle, in a normal quarter it can be 3–5 groszy per euro in either direction. On a 50,000 EUR transaction that's 1.5–2.5k PLN of difference landing somewhere in the books as "FX differences" — a line nobody reads afterwards. Across a year, in a company with foreign-currency turnover of 8–10 million PLN, you're easily looking at 40–80k PLN that you either gain or lose, and in most cases you don't know which.
The second trap: foreign-currency invoices booked wrong in JPK. Wrong rate date, a rate taken from the wrong business day, VAT converted at a different rate than the net amount. The tax office won't necessarily catch it right away, but at the first JPK audit it can mean real penalty interest for years back.
What the ERP has to handle
A properly configured ERP won't take FX decisions off your plate, but it will take manual work and sources of error off your plate. Three things that have to work.
- Automatic daily download of NBP and ECB rates — in the ERP, not in a spreadsheet. Every reasonable ERP can do this; often it's a module you flip on. In Comarch Optima it's the currency dictionary plus an auto-job; in Microsoft Dynamics 365 — an Exchange Rate Provider configuration; in enova365 — the standard currency module. The problem in 90% of SMEs is that nobody switched it on, so someone types the rate in by hand every day — and gets it wrong once a month.
- Three separate rates on every purchase and sale document — the VAT rate (the previous business day, per statute), the "cost" rate for management accounts (transaction day), and the settlement rate (payment day, calculated automatically). All three visible and comparable inside the ERP. Not in the accountant's Excel after close.
- FX bank accounts as separate analytical accounts — EUR, USD, CNY. Each one has its balance in the currency, its balance in PLN at historical rate, and its revaluation balance at month-end. The revaluation is done by the ERP, not a human. A report "open payables and receivables in EUR, value in PLN at today's rate" is one click.
This isn't the pinnacle of sophistication — it's the minimum that Polish tax law requires anyway for JPK to hold together. The difference between company A and company B is purely that company A has this in ERP and company B has it in four Excels at the accountant's desk.
Real-life example — a steel component manufacturer
We worked with a 25-person steel component manufacturer near Łódź. Comarch Optima as ERP, steel purchases from Germany in EUR (~3.2 million EUR per year), electronics for control systems from China in USD (~380k USD per year), sales mostly to Poland (PLN) and the Czech Republic (EUR, ~1.1 million EUR per year).
Before the project FX was handled like this: rates typed in by the accountant daily from the NBP table, foreign-currency invoices entered into Optima in PLN after a conversion in Excel, bank FX accounts reconciled roughly once a month, FX differences booked in bulk at quarter close. The owner knew "that USD is eating a bit of margin" but couldn't say how much.
A two-year review showed three things:
- FX differences booked outside the proper deadlines — in seven quarters, four times at a rate different from what should have applied; cumulative understatement of the tax base ~34k PLN, which at an audit would mean an additional payment plus interest.
- Nobody had ever checked whether EUR sales to the Czech Republic naturally hedged EUR steel purchases from Germany. We did a simple comparison: 1.1 million EUR of revenue against 3.2 million EUR of cost per year — meaning every 1-grosz move in EUR/PLN was worth about 21k PLN per year against the company. The owner had assumed EUR didn't affect him "because he buys and sells at the same rate".
- The settlement rate on payments to the German supplier was on average 0.8 grosza worse than the invoice-date rate — not because the bank was cheating, but because payments were sent Friday afternoon at a worse rate. Changing the payment policy to Monday morning — a non-technical change — saved ~26k PLN in a year that had been quietly evaporating in the spread.
After switching on the NBP auto-job in Optima, three separate rates on each document, and a weekly management report ("open EUR, open USD, net position, revaluation today vs. a month ago"), the owner could for the first time in years say in one sentence how much the company actually earns on foreign-currency contracts. The implementation cost 9 days of our work. The project paid for itself before the end of Q1 — not from "FX savings" (which can't be predicted) but from closing the JPK errors and shifting the payment schedule.
When to tackle this
Three thresholds where this topic stops being "someday" and starts being "now".
- FX purchases above 1 million PLN per year combined — because then a 1-grosz rate error is a four- or five-figure line item, not a rounding difference.
- Two or more FX bank accounts — because then Excel loses the plot, and the ERP has to reconcile the balance anyway, so better it does it once than that the accountant, the controller and the owner each do it independently.
- Tax audit or financial audit on the horizon — revaluations "done manually in Excel" are the first thing any auditor flags, and one of the easier JPK items to challenge.
What next
If today you can't show your company's open FX position in a minute — how many unpaid invoices in EUR, in USD, running FX difference this quarter — it doesn't mean you're losing on FX. It means you don't know whether you are. And in FX, "I don't know" almost always means "a bit more than I should be".
Start with a list of every FX bank account, every currency the company issues and receives invoices in, and the annual volume in each. One sheet of paper. If after writing it you see more than one currency and more than one account, and your ERP only runs on PLN — the first call with us is free and takes half an hour. We won't send you a quote for an ERP migration. We'll show you what can be done in the system you already have.
In FX, "I don't know" almost always means "a bit more than I should be".