If your company sells into Poland, the mandatory KSeF (Krajowy System e-Faktur) national e-invoicing platform is not something you can bolt onto Odoo with a setting. Every B2B invoice has to leave your system as a government-defined structured XML document (the FA schema), be transmitted to the KSeF API under an authenticated session, and come back with an official reference number (KSeF ID) that must live on the invoice and appear on the customer-facing PDF. Odoo core gives you account.move, tax logic, and QWeb PDFs, but it has no concept of the KSeF session lifecycle, the FA XML structure, the government authorization tokens, or the acceptance/rejection acknowledgements — so finance teams end up rekeying invoices into a separate government portal and manually copying reference numbers back, which does not scale and breaks audit traceability.

We build a dedicated connector module that lives inside your Odoo database and wires the full KSeF exchange onto the native accounting workflow. On the customer (outbound) side, posting or confirming an account.move triggers generation of a schema-valid FA XML built from your invoice lines, taxes, partner fiscal identifiers (NIP), and payment terms; the module opens an authenticated KSeF session, uploads the document, polls for the acceptance status, and writes the returned ksef_id plus timestamp back onto the invoice with a stored state field (to_send, sent, accepted, rejected). On the supplier (inbound) side, a scheduled ir.cron job queries KSeF for invoices addressed to your NIP, downloads them, and creates or matches vendor bills so nothing is lost. Everything is modeled properly — new fields on account.move via a models.Model inherit, @api.depends computes for status, ir.model.access.csv plus record rules so only accounting roles can trigger submissions, XML/OWL views for the KSeF status widget and a manual "Send to KSeF" action, a QWeb report extension that stamps the KSeF ID on the invoice PDF, and structured logging of every request/response for tax audits. Authorization credentials and the environment endpoint (test vs production) are held in encrypted system parameters, and the government session token is fetched, cached, and refreshed by the module rather than pasted by a user.

Because this is government infrastructure with strict schema validation and error semantics, we treat correctness and recoverability as first-class: failed submissions surface a readable error and a retry action rather than silently blocking the post, and a lightweight status dashboard lets your team see, filter, and re-drive any invoice stuck in rejected. The connector uses Odoo's standard API surface (the ORM internally, and the XML-RPC/JSON-RPC API where you want to trigger submissions from an external system), and we target your exact release — Odoo 17.0, 18.0, or 19.0 — noting Community vs Enterprise differences in the accounting layer so the module behaves identically on whichever edition you run.

Delivery is build-to-order: this is not an instant download. After a short scoping call we confirm your Odoo version and edition, your KSeF authorization method, whether you need outbound-only or full two-way exchange, and your multi-company/branch structure, then build against a copy of your database. Typical delivery is one working week from confirmed scope, including UAT on a staging instance against the KSeF test environment before we ever touch production. Pricing starts from $999 (indicative, single-company base scope); multi-company setups, additional integrations, deeper FA-schema field mapping, and historical data migration volume increase the quoted scope. You receive a fixed written quote after the scoping call — never a surprise on the invoice.