What is the KSeF test environment URL?

The taxpayer app on TEST is at https://ap-test.ksef.mf.gov.pl and the API at https://api-test.ksef.mf.gov.pl/api/v2. DEMO is at https://ap-demo.ksef.mf.gov.pl and production at https://ap.ksef.mf.gov.pl.

Why doesn't ksef-test.mf.gov.pl work?

Because it's a KSeF 1.0 address. In September 2025 the Ministry of Finance swapped the test environments over to KSeF 2.0 and shut the old hosts down. Today ksef-test.mf.gov.pl returns a server error. The current test address is ap-test.ksef.mf.gov.pl.

What's the difference between TEST and DEMO in KSeF?

On TEST you authenticate with a fictional identity: an invented NIP, no signature, no real data, and the data gets wiped. On DEMO you authenticate with your real NIP and a real qualified signature or Trusted Profile, but the environment is still non-production. TEST checks your code; DEMO checks your permissions and your people.

Is an invoice filed in the KSeF test environment valid?

No. An invoice filed on TEST or DEMO has no legal effect: it isn't an invoice under the VAT Act, it never reaches your VAT return, and your customer never sees it. The KSeF number and UPO you get there are technically real but worthless for tax.

Will a TEST token work against production?

No. Each environment keeps its own permission registry, so a token generated on TEST authenticates only on TEST. On production you generate a separate token or a separate certificate. The same rule applies to DEMO.

Does TEST data carry over to production?

No. These are three separate copies of the system. Invoices, KSeF numbers, UPO confirmations and permissions granted on TEST stay on TEST. On production you start from scratch and file your first invoice again.

The KSeF test environment: where it is, and how it differs from DEMO

The KSeF 2.0 test environment runs at https://ap-test.ksef.mf.gov.pl, with its API at https://api-test.ksef.mf.gov.pl/api/v2. The old KSeF 1.0 address, ksef-test.mf.gov.pl, is shut down and returns a server error. On TEST you authenticate with a fictional identity and nothing there has legal effect. DEMO is a separate environment: real NIP, real signature, still no legal effect.

KSeF has three environments, and they are not three modes of one application. They are three separate copies of the system, each with its own address, its own permission registry and its own data. Picking the wrong one costs you either a day spent working out why a token won't authenticate, or a real invoice in the national registry.

The old test address is dead, and it isn't coming back

In September 2025 the Ministry of Finance swapped the test environments from KSeF 1.0 over to KSeF 2.0. The old hosts stopped answering: https://ksef-test.mf.gov.pl/web/ returns a server error today, and ksef.mf.gov.pl is the address of the retired 1.0 version. There is nothing to fix there and nothing to log into.

That is the most common cause of "I can't get into the KSeF test system". Plenty of Polish guides, forum posts and internal rollout instructions still hand out the old address. If someone told you to create an account on ksef-test.mf.gov.pl, that instruction is simply out of date.

The current taxpayer-app addresses:

TEST https://ap-test.ksef.mf.gov.pl
DEMO https://ap-demo.ksef.mf.gov.pl
PROD https://ap.ksef.mf.gov.pl

If you're writing an integration, the API addresses are symmetrical: api-test.ksef.mf.gov.pl/api/v2, api-demo.ksef.mf.gov.pl/api/v2 and api.ksef.mf.gov.pl/api/v2. The production API contract has been frozen since 22 December 2025, so it won't shift under you mid-rollout. The current schema is FA(3), mandatory since 1 February 2026. FA(2) is dead and there's no point building on it.

Why test at all

Because KSeF has no undo. An invoice the system accepts has been issued, and the issue date is the date you submitted it (art. 106na ust. 1 of the VAT Act), not the date printed in the document. You can't delete it, you can't fix it in place, and you can't hide it. The only way out is a correction invoice, which is itself a separate document in the registry.

The worse scenario is a made-up invoice under your real NIP. That's art. 108 of the VAT Act: tax due on a document that describes no sale at all. Anyone who "just quickly checks whether it works" on production has issued themselves a liability.

A test environment protects you from four things at once:

Data mapping mistakes. Wrong VAT rate, wrong country code, wrong currency, a missing address on a buyer identified by NIP.
Configuration mistakes. A token without the right permission, the wrong context NIP, an expired certificate.
Process mistakes. You don't yet know what a rejection looks like, where the UPO lives, or what to do when a session dies halfway through.
Nerves on the first real invoice. Someone who has walked the whole path on TEST already knows what they'll see the first time it counts.

TEST isn't only for the start. You come back to it when you change invoicing systems, when you issue a document type for the first time (a correction, an export of services, EU reverse charge), when you move from a token to a certificate, or when a new schema version lands. Every time, it's the same job: check the shape of the document somewhere a mistake costs nothing.

The three KSeF environments: TEST, DEMO and PROD

Environment	Authentication	Identity	Data persistence	What it's for
TEST `ap-test.ksef.mf.gov.pl`	fictional, no signature	invented NIP, nothing real	wiped periodically, don't rely on it	first contact, integration work, automated tests
DEMO `ap-demo.ksef.mf.gov.pl`	real: qualified signature, company seal or Trusted Profile	your real NIP	non-production, no legal effect	dress rehearsal with real permissions
PROD `ap.ksef.mf.gov.pl`	real	your real NIP	permanent, full legal effect	real invoices and nothing else

The whole practical difference sits in the "authentication" column. TEST accepts invented identities, so you're in within a minute, with any NIP that passes its checksum and no signature at all. DEMO requires a real qualified signature or Trusted Profile, exactly like production. Get those two mixed up and you lose days: either waiting for a certificate you never needed, or trying to log into DEMO with a made-up NIP and not understanding why it bounces.

How to get into TEST

Open https://ap-test.ksef.mf.gov.pl.
Authenticate with a test identity. You don't give real company data and you don't need a signature. A structurally valid NIP is enough.
In the taxpayer app, generate a token for that environment, or register a certificate if you want to practise the method you'll actually use.
Paste it into your integration pointed at api-test.ksef.mf.gov.pl/api/v2 and file your first invoice.

What you can do there:

File an invoice and walk the full status cycle, through to the KSeF number and UPO.
See a rejection with a real error code, and learn to read it before you meet it on production.
Issue a KOR correction referencing the original KSeF number.
Practise granting permissions, to your accountant for example.
Generate a QR code and check what the buyer will see.
Run your integration's automated tests as many times as you like. Nothing leaves the sandbox.

We cover the choice of authentication method separately in token or certificate, and the API details in KSeF API.

When DEMO is the better choice

DEMO earns its place when what you're testing isn't code but people and permissions. The typical cases:

You want to confirm that your qualified signature or company seal really works in KSeF before you go live.
You're granting permissions to an accountant or an employee and want to see what they will see.
You're running a dress rehearsal of the whole issuing process against your real org structure.

It costs you real authentication: a qualified signature, a company seal or a Trusted Profile. If you have none of those yet, DEMO starts with obtaining a certificate or a profile, not with your first API call. Which is why the order that holds up is: TEST first, because you're in within a minute and you'll catch most of the mistakes there; then DEMO if you need to check permissions; production last.

If you're integrating on your own and don't have a complex permission structure, you can skip DEMO entirely. Plenty of one-person sellers go from TEST straight to PROD, and that's fine.

What a test filing proves, and what it doesn't

It proves concrete, useful things:

Your token or certificate authenticates correctly.
Your XML passes FA(3) schema validation.
The document's tax classification is what you expected.
The whole loop works: submission, status, KSeF number, UPO, correction.

What it does not prove, though people assume it does:

It proves nothing to the tax office. An invoice from TEST or DEMO is not an invoice under the VAT Act. It doesn't reach your VAT return, your customer never sees it, and it doesn't count towards JPK.
It doesn't confirm production permissions. Permissions are granted per environment. Your accountant seeing your invoices on TEST says nothing about PROD.
It doesn't protect a deadline. A test filing stops no clock and replaces no obligation to issue.

A KSeF number and UPO from TEST are technically real and worthless for tax. They look exactly like the production ones, and that's precisely what trips people up.

The most common mistakes

The old 1.0 address. You type ksef-test.mf.gov.pl, get an error, and conclude KSeF is down. It isn't. It moved.

A TEST token sent to the production API. Each environment keeps its own permission registry, so a token only authenticates where it was created. The symptom is misleading: it doesn't look like "wrong address", it looks like "wrong token". Check first whether the host and the token come from the same environment.

Assuming the data carries over. Nothing migrates from TEST to production. Not invoices, not numbers, not permissions. On production you grant permissions again and generate a new token.

Testing on production because "it's only one invoice". There is no production sandbox. Every document filed to PROD is real, with full effect, and the only cleanup is a correction to zero.

Crossing Stripe test mode with KSeF production. If you file invoices from Stripe, keep them paired: Stripe test mode with KSeF on TEST, Stripe live mode with KSeF on PROD. Crossing those two axes sends test data into the real registry.

Not being sure where you actually are. Check three things in order: the address in your configuration (api-test, api-demo or api), the environment you generated the token in, and what your invoicing tool reports. If any one of those disagrees with the others, that's your bug. In the taxpayer app the same check is the address bar: ap-test, ap-demo or ap.

How KSeF Kit handles this

In KSeF Kit the environment is an explicit account switch, not a setting in a file. In the connection wizard, TEST is selected by default — an accidental PROD is the nightmare, so choosing the environment is the first step, not the last. Credentials are stored separately per environment, so switching between TEST and PROD never overwrites a stored token.

Before you save anything, the "Test connection" button tries to authenticate against the chosen environment using your method and returns a clean pass or fail. Once you're connected to TEST or DEMO, you land on the test filing step: you pick an invoice shape close to your own (domestic B2B at 23%, an EU customer under reverse charge, a non-EU customer under export of services, or simply your latest real invoice), we file it down the same path production uses, and we show you the KSeF number and the UPO. You can file a test correction straight afterwards to see what happens on a refund.

Going to PROD requires separate production credentials and an explicit confirmation, and it ends on a screen that says plainly what just changed. We never file a synthetic sample on production: a fresh PROD account gets a calm "you're live" message, and your first real Stripe invoice files itself.

Start on TEST, file one test submission, look at the number and the UPO, and only then switch to production. The full path an invoice takes is described in how to issue a structured invoice.