Polish invoicing carries requirements Odoo core does not fully express out of the box: an invoice must carry the correct legal document type and a numbering series that resets and formats to Polish convention, the NIP has to be validated and printed, the seller and buyer identification block has to match what Polish tax authorities and buyers expect, and the printed faktura layout has to read the way a Polish accountant and auditor expect it to read. Teams running Odoo in Poland typically bolt these on with ad-hoc ir.sequence records, manual field entries, and a hand-edited QWeb template — which drifts every time someone touches the accounting configuration and breaks quietly on the next version upgrade. Invoice PL is the base layer that ends that drift: a single, versioned foundation the rest of your Polish accounting stack sits on.

What we build is a proper Odoo module, not a settings tweak. It extends account.move and account.move.line with the Polish-localization fields the invoice needs — legal document type, NIP handling, and the identifiers that belong on a faktura — added through the ORM as fields on the model with compute/@api.depends logic where a value is derived rather than typed. Document numbering is wired through dedicated ir.sequence series so each legal document type gets its own consistent, gap-aware series in the Polish format instead of Odoo's default counter. The printed document is a purpose-built QWeb report that inherits the standard invoice action, so it prints from the same buttons your team already uses. Access is governed by ir.model.access.csv plus record rules so the new fields respect existing accounting groups, and where a step should happen without a click — stamping a document type on confirmation, for example — we use Odoo automated actions rather than brittle manual process. Everything is packaged with a clean __manifest__.py declaring dependencies on the accounting base, so it installs, upgrades, and uninstalls like any first-class app.

Because it is a base module, it is designed to be extended: the fields and sequences it exposes are stable anchors that KSeF/e-invoice logic, JPK reporting, or split-payment features can depend on, and every value it manages is reachable over the XML-RPC/JSON-RPC API for integrations with external billing or e-invoicing platforms. It targets Odoo 17.0, 18.0 and 19.0, and we build against your edition — Community or Enterprise — since the accounting base and some localization hooks differ between the two; we confirm which during scoping so the dependency graph in the manifest is correct for your database.

Delivery is build-to-order. After a short scoping call we confirm the exact document types, numbering rules, field set, and print layout you need, then build against a copy of your database, prove it on a staging instance through UAT, and deploy with a rollback plan. Typical delivery is 2–4 weeks from confirmed scope, depending on how much of your existing invoicing data needs to be reconciled to the new series. Pricing starts from $299 (indicative, single-company base scope); additional legal document types, multi-company deployment, migration of historical invoice numbering, and integration with downstream e-invoicing systems increase the quoted scope. You receive a fixed quote after the scoping call — never a surprise on the invoice.