Poland KSeF E-Invoicing Compliance

The problem

KSeF is not a reporting format bolted onto an existing invoice — it is a different way of issuing one. A Polish invoice becomes legally issued when KSeF accepts it and assigns a KSeF number, and the UPO (Urzędowe Poświadczenie Odbioru) is the proof. The submission itself is session-based: authenticate, open a session, send the FA(3) structured XML, poll the status, retrieve the UPO, close the session. None of that resembles running a tax report at month-end, which is why generic tax reporting features cannot produce it.

NetSuite ships nothing for this. There is no FA(3) generator, no session handling, no place to store a KSeF number or a UPO document against the transaction, and no inbound path for the purchase invoices your suppliers will issue to you through the same system. Handling it manually means an operator uploading files and copying reference numbers back — which does not survive real volume, and leaves you unable to answer the one question that matters in an audit: prove this invoice was accepted, and show me the confirmation.

What ECOSIRE builds

A build-to-order SuiteScript 2.1 project, delivered as an unmanaged bundle or SDF project you own. Scoped against your account, built, installed in sandbox, then production, then supported.

FA(3) structured XML generation

A Map/Reduce script generates the FA(3) structured invoice XML from NetSuite Invoice and Credit Memo records, mapping the required blocks: Podmiot1 seller identification with NIP and address, Podmiot2 buyer identification, Fa header carrying invoice number, P_1 issue date, P_6 date of sale, currency and exchange rate, the FaWiersz line elements with description, quantity, unit net price, net value, VAT rate and line totals, plus the VAT summary fields and the invoice type (basic, correcting, advance, settlement) with references to a corrected original where applicable.

Mapping is not a guess. It is agreed as a field-level table during scoping, then implemented against it, so what the schema requires and what your NetSuite data holds are reconciled before development, not during testing.

Session-based submission and UPO

The submission engine handles the full KSeF lifecycle from Scheduled and Map/Reduce scripts: authentication using your chosen credential method, session initialisation, invoice send, status polling with backoff, UPO retrieval and session close. Tokens and keys are held in NetSuite secure strings via N/https, never in readable custom fields. The KSeF reference number and the retrieved UPO are written back to the transaction and the UPO document is attached to the record in the File Cabinet, so the proof lives beside the invoice rather than in a download folder on someone's laptop.

Because the process is asynchronous, status is treated as a first-class state machine: draft, queued, sent, pending confirmation, accepted with KSeF number, rejected with error code. A transaction never silently sits in an ambiguous state.

Inbound invoices

A Scheduled script queries KSeF for invoices issued to your NIP, downloads the FA(3) XML, and creates a Vendor Bill or a staged custom record for review — your choice, agreed in scoping. Vendor and item matching rules are built against your master data. This is the half of KSeF that teams routinely forget until go-live, and it is the half that determines whether AP keeps working.

Corrections, attachments and evidence

Correcting invoices are submitted with the correct type and a reference to the original KSeF number, keeping the correction chain intact. Every submission attempt writes to a custom record — request, response, session identifier, KSeF number, UPO reference, status code, error text, retry count — and saved searches expose the pending, rejected and unconfirmed queues so nothing is discovered a week later.

VAT, currency and multi-entity

Polish VAT rate mapping is driven by a maintainable configuration record rather than hardcoded rates, covering standard, reduced, zero-rated, exempt and reverse-charge treatment. Foreign-currency invoices carry the exchange rate and date required by the schema. In OneWorld, each Polish subsidiary holds its own NIP, credentials and configuration, so a shared instance does not cross-submit between entities. Custom segments feed your internal reporting, not the statutory payload, unless your scope says otherwise.

Who it is for

Polish taxpayers running NetSuite that must issue structured invoices through KSeF: local companies, and international groups with a Polish subsidiary inside a OneWorld account. It fits teams that want NetSuite to remain the system of record — issuing, confirming and archiving from one place — rather than operating a parallel process in a separate tool and reconciling afterwards.

How delivery works

1. Scoping call. We review your NetSuite version and edition, OneWorld or single instance, in-scope transaction types, VAT code configuration, currency handling, invoice numbering, your KSeF authentication approach, and whether inbound purchase invoices are in scope. We work from real records.

2. Fixed quote. A written scope naming every script, custom record, field and mapping, with the FA(3) field-level mapping table, stated assumptions and a fixed price.

3. Build. SuiteScript 2.1 and SDF development in your sandbox or a development account, built against the agreed mapping.

4. Install in test. Sandbox install first. We validate generated FA(3) XML against the schema and run submissions against the KSeF test environment using your own invoices — corrections, foreign currency, multi-rate VAT lines and all.

5. Production install. After sandbox sign-off we install into production, load per-entity configuration, set deployment statuses and role permissions, and run a supervised first live batch with your team present.

6. Support. A defined support window covering defect fixes, mapping adjustments and team questions. Later schema versions or rule changes are quoted separately, and we will always say plainly which side of that line a request falls on.

Lead time is typically one working week from signed quote to sandbox install, extending when inbound processing, multiple subsidiaries or complex correction handling are in scope, or when test-environment credentials take time to arrive.