Overview
Building a KSeF integration yourself means generating FA(3) XML, authenticating to KSeF, sending encrypted invoices and polling their status; using a KSeF API means you send plain JSON and the provider owns the rest. For most SaaS and e-commerce teams, an API like Notaly is faster and cheaper to ship and maintain. Build your own only if you already run a full e-invoicing stack and need maximum control.
What building this yourself actually means
KSeF (Krajowy System e-Faktur) is Poland's national e-invoicing platform run by the Ministry of Finance (Ministerstwo Finansów). To submit an invoice programmatically you generate a structured invoice in the FA(3) format — the XSD schema published at crd.gov.pl — authenticate to KSeF, open an online session, send the encrypted invoice, then poll the status until you receive the UPO, the official proof of receipt.
Building this in-house means owning several moving parts. First, FA(3) generation: you map the seller, buyer, line items and VAT onto the schema, including fields such as P_1 (issue date), P_2 (invoice number) and P_15 (total amount due). Second, authentication: you either sign the KSeF authentication challenge with XAdES (a qualified signature or seal, or a KSeF certificate) or authenticate with a KSeF-issued token, encrypted with the Ministry of Finance public key together with the challenge timestamp. The invoice XML itself is not signed — it is encrypted and sent in an online session. Third, submission and status: you call the KSeF endpoints and interpret the status codes it returns. Fourth, operations: you store invoices, watch for failures, retry submissions and keep up with new schema versions the Ministry publishes.
Why teams pick the API route
A KSeF API such as Notaly's collapses that pipeline into a single call. You send a JSON invoice to POST /invoices; Notaly generates the FA(3) XML, validates it against the official XSD, authenticates to KSeF with the token you provide in Connect KSeF (no qualified seal needed), sends the encrypted invoice and reports the status and UPO back through a webhook. You never write XML or XAdES code, and you do not track schema changes yourself.
The trade-off is control versus cost. Building in-house has no per-invoice API fee but takes weeks or months of engineering and a steady maintenance effort. An API has a subscription but starts returning value the same day, which is usually the better deal for a team whose core product is not e-invoicing.
When building yourself makes sense
Build in-house if you already operate an invoicing or accounting product in Poland, you have a team for XML and cryptography, and you need features beyond standard submission, such as bespoke archival or offline workflows. For everyone else — a WooCommerce or Shopify store, a SaaS billing engine, or a finance team that wants e-invoicing without a government-integration project — the API route is usually the safer default.
If you are still evaluating, start in the KSeF TEST environment: it issues test invoices against the same FA(3) schema without touching production data.
Disclaimer
Notaly is not a tax, accounting or legal advisor. This article is general information, not tax advice, and may be outdated. You are responsible for your own VAT compliance; confirm with a qualified accountant where required.
Sources
Source: www.podatki.gov.pl