E-Invoice Finder
Menu
Countries Compare software Deadlines Guides Checker Check obligation
ENFRDEPLNL
Poland · KSeF migration operations

KSeF historical backfill and ERP cutover plan

Plan a controlled KSeF invoice backfill, ERP cutover and reconciliation with HWM boundaries, rollback criteria and auditable evidence.

Quick verdict:
  • Scope every access role before fixing the migration population.
  • Identity mismatches outweigh reassuring aggregate totals.
  • Approve the switch only after a witnessed recovery rehearsal.
Get Poland readiness reportOfficial sources
Last checked: 29 July 2026Based on official sourcesClear summaryBusiness guidance, not legal advice
Official sources prioritized
Last-checked dates visible
Free checker, no signup required

What you need to know

Guide

Scope and historical boundary

Start with a frozen scope manifest listing each legal entity, KSeF environment, SubjectType, approved historical start date and target ERP company or ledger. Access may arise as Subject1, Subject2, Subject3 or an authorized subject, so maintain an independent continuation state for every entity, environment and SubjectType rather than one company-wide cursor. Choose the import depth from documented business needs, available access, legacy coverage and adviser input; the cited technical guidance sets no universal backfill period. Use asynchronous POST /invoices/exports, which the official KSeF 2.0 integrator documentation recommends for incremental synchronization with an external local database. For stable retrieval, set restrictToPermanentStorageHwmDate=true. PermanentStorageHwmDate is a completeness boundary: records at or before it form a closed set, while newer records may still appear. Record the selected first boundary and cutover boundary in the approved manifest. These migration controls are recommended operational practice, not statutory KSeF requirements or legal or tax advice.

Guide

Source/target data model and provenance

Map the KSeF XML and _metadata.json fields into a durable canonical invoice record before mapping them into ERP posting structures. Preserve the KSeF number, business invoice number, seller and buyer identifiers, KSeF receipt date, issue date, source role, environment, export run, package part and legacy or new ERP record IDs. The KSeF number is the safe technical idempotency key; a supplier business invoice number can repeat across suppliers, years or systems and must not be the sole duplicate key. Keep the KSeF receipt date separate from retrieval time: receipt occurs when KSeF assigns its number, not when a connector downloads the file. Preserve old/new-system provenance from each posting to its canonical XML and migration run. KSeF transport completeness is not the same as ERP acceptance, tax coding, matching or posting. Downloading an invoice proves neither accounting acceptance nor successful reconciliation, and KSeF should not be described as replacing the company's archive.

Guide

Repeatable pilot backfill

Run a bounded, production-like pilot with the cutover code, security and checkpoint rules. For example, suppose Subject2 begins at 1 June 00:00 and an export returns PermanentStorageHwmDate 7 June 12:00, IsTruncated=true and LastPermanentStorageDate 4 June 18:30. After downloading every encrypted ZIP part, decrypting with the export key and IV through the documented AES-256 process, assembling and unpacking the package, and reconciling XML against _metadata.json, durably commit the canonical records. Continue the next window from 4 June 18:30. If that next result is not truncated and its HWM is 7 June 12:15, commit it and continue from 7 June 12:15. Adjacent windows share the preceding endpoint, so deduplicate the overlap by KSeF number. Repeat the pilot from a clean target and compare results. Never move a checkpoint merely because the download completed; move it only after package evidence and canonical records are durably committed.

Guide

Reconciliation and exception handling

Reconcile at identity level, not only by totals. First compare expected package parts with received parts; then compare _metadata.json entries with XML files and unique KSeF numbers; then compare canonical records with target ERP import, posting and rejection outcomes. Break counts down by stream, window and status so equal totals cannot conceal an omission and unrelated duplicate. Route missing XML, metadata-only entries, duplicate identities, schema failures, counterparty mismatches and ERP validation errors to an owned exception queue without advancing data into an unexplained state. Common mistakes include using the supplier invoice number as the key, skipping the shared boundary, combining role checkpoints, treating local download time as receipt date, and counting a staged record as posted. Retain the signed-off manifest, boundaries, counts, exception decisions and target commit references. Reconcile again after corrections; avoid adjustments that system evidence cannot reproduce.

Guide

Cutover sequence and ownership

Publish a timed runbook with owners for extraction, security, storage, ERP loading, reconciliation, finance acceptance and incident command. Freeze scope and mapping changes, complete the final bounded export windows, drain package processing, reconcile the canonical store, pause the legacy writer, load or release approved records to the new ERP, and perform identity and posting checks before declaring the source-of-truth switch. A practical go decision requires all scoped role streams to reach their approved closed HWM boundaries, every package part and metadata identity to reconcile, zero unexplained high-severity exceptions, tested access and monitoring, an available rollback owner, and finance approval of the posting results. A no-go applies if a checkpoint is ambiguous, a package is incomplete, critical identities differ, two writers can run, or recovery evidence is missing. The sequence and approvals are recommended cutover controls; the official KSeF materials establish retrieval behavior, not this project-governance model.

Guide

Dual-run and source-of-truth controls

A short dual-run may help comparison, but define its purpose and authority first. Keep only one checkpoint writer for each entity, environment and SubjectType; a second process may observe or reconcile but must not independently advance the same stream. Mark whether the legacy ERP, canonical KSeF store or new ERP owns each action: retrieval state, invoice identity, accounting enrichment, workflow decision and posting. Use read-only comparison feeds or idempotent shadow loads rather than two uncontrolled posting paths. At the declared switch, record the exact boundary and disable the old writer with evidence. Label records beyond the last closed HWM provisional because that newer set may remain incomplete. Dual-run is not automatically safer: without explicit authority it creates conflicting edits, duplicate postings and an unclear audit trail. End it once acceptance criteria are met rather than allowing permanent split ownership.

Guide

Rollback and legacy access

Define rollback triggers before go-live: unrecoverable identity gaps, corrupted canonical data, critical posting errors above the approved threshold, unavailable security controls or inability to resume from the recorded boundary. Separate a business-process rollback from a transport rollback. The KSeF canonical store and committed checkpoints should remain intact if finance temporarily returns posting to the legacy ERP; rewinding them without analysis can create duplicates or gaps. Record who can declare rollback, the deadline for that decision, which interfaces stop, how queued items are isolated and how reconciliation will restart. Keep the legacy ERP read-only for historical evidence and unresolved references under company access and retention policies. Do not invent a statutory retention period from these technical sources. Test rollback in a dress rehearsal, including restoration of routing and permissions. A rollback boundary is recommended migration control, not an official KSeF mandate.

Guide

Hypercare, security and audit evidence

During hypercare, monitor the age of each committed HWM, truncated exports, expected versus received ZIP parts, decryption failures, metadata/XML differences, duplicate KSeF numbers, exception age, ERP queue depth, posting failures and unauthorized manual runs. Handle HTTP 429 by honoring Retry-After; consult the current official limits documentation as runtime truth because limits may change. Protect credentials, export keys, IVs, invoice payloads and staging locations with least privilege, environment separation, encrypted storage and controlled deletion. Keep sensitive data out of routine logs and dashboards. Evidence should include frozen scope, mappings, export boundaries, package inventory, reconciliation results, checkpoint commit ID, approval, switch time, rollback decision and exception closure. Run daily identity reconciliation until agreed exit criteria are met, then transfer ownership to normal operations. Hypercare and its evidence pack support controlled operations but do not convert technical retrieval into tax or accounting approval.

Guide

Vendor decision criteria and topic-specific next actions

Ask a KSeF migration or connector vendor to demonstrate a clean backfill twice and produce identical KSeF-number sets. Require separate state by entity, environment and SubjectType; correct branching from LastPermanentStorageDate when IsTruncated=true and from PermanentStorageHwmDate otherwise; shared-boundary deduplication; complete multipart AES-256 processing; _metadata.json reconciliation; and atomic canonical commit before checkpoint movement. Test 429 handling, missing parts, decryption failure, commit-time crashes, role overlap and blocked concurrent writers. Require auditable acceptance evidence and clear responsibility for mapping exceptions, rollback and legacy access. Next, approve the scope manifest, nominate owners, select the first bounded pilot, define identity and posting tolerances, rehearse cutover and rollback, and review results with finance, tax and security stakeholders. Reject guarantees that KSeF replaces archival obligations or that successful download proves accounting acceptance.

Guide

Practical question summary

For KSeF historical invoice backfill and ERP cutover: Most KSeF questions are about who must use the system, whether current accounting software is ready, how authentication works, how corrections are handled, whether ecommerce or ERP needs API integration, and how accountants access invoice data. This guide focuses on those operational decisions.

Guide

Decision framework for businesses

For KSeF historical invoice backfill and ERP cutover: A KSeF-ready workflow should show who creates invoices, who submits them, who monitors status, who handles rejection or correction, how invoices are archived and how the accountant sees the records.

Guide

How to use this guide

Use this guide to decide whether KSeF historical invoice backfill and ERP cutover affects your Poland workflow and which evidence is still missing. Start with KSeF authentication, structured invoice submission, invoice status handling, then test submit a KSeF invoice and simulate an API rejection before comparing software.

Guide

Data and terms to prepare

For KSeF historical invoice backfill and ERP cutover, the important terms are KSeF historical invoice backfill and ERP cutover, Poland, KSeF authentication, structured invoice submission, invoice status handling, corrections and rejections, accounting or ecommerce integration. Clean these fields in customer, supplier, tax and accounting records before rollout; otherwise validation and support issues appear during daily invoicing.

Guide

Software proof to request

For KSeF historical invoice backfill and ERP cutover, ask vendors to show show KSeF authentication, submission status, corrections, permissions and accounting export using your examples. The demo should cover submit a KSeF invoice, simulate an API rejection, create a correction, verify user permissions and explain who handles errors, corrections, archive access and accountant handoff for KSeF authentication, structured invoice submission, invoice status handling.

Guide

Evidence before rollout

Keep official links, screenshots, test invoices and the decision reason for KSeF historical invoice backfill and ERP cutover. For KSeF historical invoice backfill and ERP cutover, the implementation file should prove how KSeF authentication, structured invoice submission, invoice status handling, corrections and rejections were checked, not just that a tool was selected.

Guide

Decision checkpoint

Do not close KSeF historical invoice backfill and ERP cutover until someone can explain KSeF historical invoice backfill and ERP cutover in Poland, name the workflow owner, show one tested invoice scenario and describe how the team avoids choosing software for Poland before proving the real KSeF historical invoice backfill and ERP cutover workflow.

Checklist

Freeze a manifest of entities, environments, SubjectTypes, historical start dates and target ERP companies.

Assign a separate continuation record and single checkpoint writer to every scoped retrieval stream.

Use stable PermanentStorage HWM windows and document the approved cutover boundary.

Download, decrypt, assemble and verify every encrypted export part before processing invoices.

Reconcile _metadata.json, XML and canonical KSeF-number sets for every backfill window.

Commit canonical records durably before advancing from LastPermanentStorageDate or PermanentStorageHwmDate.

Queue mapping and ERP posting exceptions with owners, severity and reproducible resolution evidence.

Rehearse the complete cutover and rollback with production-like volume and security controls.

Record explicit go/no-go approval, source-of-truth ownership and the exact switch boundary.

Monitor HWM lag, package integrity, 429 responses, ERP outcomes and exception ageing through hypercare.

FAQ

How far back should an initial KSeF invoice import go?

Choose a date from documented business, accounting, audit and migration needs, then confirm it with qualified advisers and the data available to each scoped entity and role. The cited KSeF technical guidance explains retrieval mechanics but does not provide one universal historical period. Freeze the approved start so every rehearsal uses the same population.

Where should we set the KSeF ERP cutover boundary?

Use a recorded closed PermanentStorageHwmDate for each entity, environment and SubjectType, not the wall-clock moment when a download finishes. Records at or before that HWM form the stable set. If an export is truncated, continue from LastPermanentStorageDate and keep processing until the approved boundary is reached and durably reconciled.

How do we reconcile a KSeF backfill before go-live?

Compare all expected and received package parts, then match _metadata.json to XML by KSeF number, canonical storage to committed package records, and ERP imports and postings to the canonical set. Segment by stream and window, investigate identity differences, and retain decisions. Matching totals alone are insufficient because one missing invoice can offset one duplicate.

Should we dual-run the legacy and new ERP?

A bounded comparison period can be useful, but only with explicit source-of-truth rules. Never allow both systems or connectors to write the same KSeF checkpoints, and avoid uncontrolled dual posting. Define what the shadow system may do, when the comparison ends and which recorded boundary transfers authority.

When should a KSeF cutover be rolled back?

Use pre-approved triggers such as unexplained identity gaps, incomplete packages, critical posting failures, unavailable controls or inability to resume safely. Preserve committed canonical records and checkpoints unless investigation proves they are wrong; returning finance processing to the legacy ERP does not automatically justify rewinding transport state. Name the decision owner and deadline in advance.

How can migration avoid duplicate KSeF invoices?

Enforce uniqueness by KSeF number and expect adjacent retrieval windows to overlap at the preceding endpoint. Keep independent checkpoints by entity, environment and SubjectType, and prevent concurrent writers. A supplier's business invoice number alone is not a safe idempotency key, while a replay after a crash should converge through the KSeF-number constraint.

Does KSeF replace the company's invoice archive?

Do not assume so. The cited materials describe KSeF retrieval, HWM behavior, export packaging and technical limits; they do not establish that a download replaces company archival obligations. Define storage, evidence, access and retention with the organization's legal, tax, accounting and security advisers, and keep legacy access where the migration plan requires it.

What evidence should a KSeF migration vendor provide for acceptance?

Require repeatable pilot results, stream-specific HWM and truncation records, package-part inventory, decryption and _metadata.json reconciliation evidence, unique KSeF-number sets, atomic commit behavior, 429 handling, recovery tests, blocked concurrent writers and an executed rollback rehearsal. Also verify ERP posting outcomes separately from KSeF transport completeness and obtain named ownership for unresolved exceptions.

What do businesses usually ask about KSeF?

For KSeF historical invoice backfill and ERP cutover: They ask about software readiness, API integration, authentication, corrections, accountant access and ecommerce workflows.

What is the most practical KSeF risk?

For KSeF historical invoice backfill and ERP cutover: The practical risk is late discovery that permissions, corrections or invoice status handling do not match the business process.

What should I test first for KSeF historical invoice backfill and ERP cutover?

For KSeF historical invoice backfill and ERP cutover, start with submit a KSeF invoice, simulate an API rejection, create a correction because those scenarios reveal whether the workflow is practical.

What is the main risk for KSeF historical invoice backfill and ERP cutover?

The main risk is choosing software for Poland before proving the real KSeF historical invoice backfill and ERP cutover workflow.

Key regulations, formats and terms

PolandKSeFKrajowy System e-FakturPolish Ministry of Financepodatki.gov.plstructured invoiceAPI authenticationinvoice correctionsaccounting softwareVATSMEecommerceEuropean CommissioneInvoicingEN 16931Directive 2014/55/EUstructured electronic invoiceVAT automationcross-border tradeKSeF historical invoice backfill and ERP cutover

Poland — Country hub

Poland

Open country hub →

Use the country hub to see every related deadline, checklist, format guide and software comparison for this market.

Continue reading

Official sources

We prioritize official government and EU sources where available and keep last-checked dates visible for mandate-sensitive pages.