Odoo Accounting Consultant in Poland

Fiscal positions: getting VAT right without asking users

A Polish manufacturer or distributor in Odoo might sell to a domestic customer, a German business customer, a buyer outside the EU and a consumer, all in the same week. Each needs different VAT treatment and different markings in the statutory data. If users have to choose the tax manually on every line, errors are guaranteed.

Odoo handles this with fiscal positions: rules on the customer or supplier that replace the default tax with the correct one. With your accountant, I design positions for the cases your business meets:

• Domestic sales and purchases using the standard Polish taxes from the localization.
• Intra-EU supplies of goods to customers with a valid EU VAT number, and intra-EU acquisitions from suppliers.
• Services bought from or sold to foreign businesses, where reverse charge may apply.
• Exports and imports outside the EU, with customs documents referenced where your accountant wants them.
• Any special cases your accountant flags, such as goods where the buyer accounts for VAT domestically.

Fiscal positions can be assigned automatically based on the partner's country and VAT number, which is far safer than relying on staff. Each position is then tested with real invoices and the VAT report is compared with the accountant's expectations. The treatment itself is your accountant's decision; I make sure Odoo applies it consistently. The general Odoo Accounting page explains fiscal positions in more detail.

Journals, KSeF exchange and the data behind JPK

Polish statutory output depends on how the accounting is structured, not only on an export button. I design journals and document types first, then test what comes out.

Journals: separate sales journals where your accountant wants different numbering, for example for domestic and export invoices; a correction journal or clearly marked credit notes; purchase journals that keep supplier invoice numbers and dates of receipt; and cash journals if you still handle petty cash.

For invoice exchange with KSeF, the route depends on your Odoo version and edition and possibly on a module from a Polish provider. Whichever route you use, I test from the accounting side: the identifier stored on the posted invoice, correction invoices linked to their originals, inbound supplier invoices reaching the vendor bill queue, and what the accountant sees when a submission fails. The comparison of routes themselves sits on my Odoo in Poland page.

For JPK files, I work with your accountant to list the data each file needs and trace it to its origin in Odoo: partner VAT numbers, tax tags on each tax, document dates, and markings that some transactions require. Test entries go through the full cycle, and your accountant reviews sample output before go-live. Missing data is fixed at source with mandatory fields and validations rather than patched every month. Scope and timing of the rules are for your tax advisor to confirm.

Exchange rates, banks and month end in PLN

Polish entities trading in EUR face two currency questions: which rate values a foreign invoice for VAT and bookkeeping, and how open balances are revalued at period end. Your accountant decides the rules, usually built around the National Bank of Poland rate tables. Odoo can load rates automatically from several providers; check whether the provider your accountant needs is available in your version, or set up a reliable manual or scripted import.

The month-end routine I set up includes:

• Currency revaluation of open receivables, payables and foreign bank balances, posted to the accounts your accountant chooses, reversed when the following period opens, if your policy says so.
• Bank reconciliation using statement files from your Polish banks, or bank synchronization where available, with reconciliation models for recurring items such as fees, card settlements and regular suppliers.
• Split payment handling, where it applies, with payments to or from the separate VAT account recorded correctly.
• Supplier bank account verification against the official VAT taxpayer register as a step in the payment approval process, using an available module or a manual check.
• Accruals and prepayments posted through deferred revenue and expense features where your edition includes them.

A short close checklist in Odoo keeps these steps in order and lets the chief accountant see what is done. The multi-currency ERP page discusses rate design across systems.

Intercompany and group reporting from one Odoo database

Many Polish Odoo users are part of a group: a plant selling to a German or Nordic sales company, or a shared service entity charging management fees to sister companies. A single Odoo database can host the Polish entity next to companies from other countries, keeping a distinct localization, tax set, chart and currency for every one of them, and that gives group finance some useful options.

• Intercompany rules can create the mirror document automatically, so a sales invoice from the Polish company becomes a vendor bill in the buying company. I check that taxes and fiscal positions on both sides are correct, since the two companies may sit in different countries.
• Group chart mapping: the Polish chart stays statutory, while each account maps to the group chart for consolidation. Odoo's consolidation features depend on edition and version, so I confirm what is available or design an export to the group's reporting tool.
• Transfer pricing documentation is for your advisors, but Odoo can apply agreed intercompany price lists consistently.
• Access rights keep each company's users within their own books, while group finance sees across them.

Before committing to one database, I check that every country's localization is maintained to a similar standard. If one country's needs would distort the shared setup, a separate database feeding consolidation can be wiser. The multi-company ERP page covers the trade-offs in general.

Community, Enterprise and when Odoo Accounting is not enough

For accounting specifically, the edition question is sharper than for operations. Odoo Community provides invoicing and core accounting, but several finance features many Polish teams expect, such as parts of reconciliation, reporting and some localization pieces, may depend on Enterprise in your version. Community users often fill gaps with modules from the Odoo Community Association or Polish providers. That can work, but each module must be maintained through upgrades, and statutory modules with no clear maintainer are a risk. I list exactly which finance features you need and where each comes from before the edition is chosen.

There are cases where I would advise against running Polish books in Odoo:

• Your accounting office will only work in its own system, and the business does not want to bring bookkeeping in-house. Odoo can still run operations and pass documents to the office.
• The group mandates Microsoft, where Dynamics 365 in Poland is the realistic choice.
• No maintained e-invoicing route exists for your version, and waiting is not an option.

I work remotely, in English, with your accountant reviewing outputs; Polish-language invoice layouts come from the implementer or your team. My wider approach is set out in the Poland hub and on my Polish ERP consulting page.