New Invoice Notifications in KSeF

KSeF does not automatically send system notifications when a new invoice is received. A document may already be available to the buyer in the system even though nobody at the company has received an email, SMS or other alert.

KSeFGPT can provide this additional layer: it periodically checks invoice metadata in KSeF, identifies a new document and starts an automation. The default workflow sends an individual or batch email, while a custom notification action can use email, Slack, Telegram or a webhook.

An alert helps start processing the document, but it does not mean that the invoice has been read, approved or posted. It must also be distinguished from a message sent after an outgoing invoice is submitted and from its status, KSeF number and UPO.

A supplier issued an invoice, KSeF accepted it and the document is available to the company. Even so, the accounting team, the person who placed the order and the business owner received no message. This does not necessarily indicate an outage or an error by the seller, because KSeF itself does not act as an inbox that sends an alert about every new document.

The Polish Ministry of Finance explains that the taxpayer's software should query KSeF and that a notification function can be implemented locally in the accounting software being used. In practice, there are therefore three separate moments: the invoice becoming available in KSeF, the application detecting it and the alert being delivered to a person. A company should understand this distinction before establishing its document workflow.

1. Does KSeF send notifications about new invoices?

2. How does software detect a new invoice in KSeF?

3. Three events that should not be confused

4. What should a good alert contain?

5. How should notifications be routed to the right people?

6. A notification does not mean approval or posting

7. How does KSeFGPT turn a new invoice into action?

8. Frequently asked questions

A well-designed notification connects an event in KSeF with clear responsibility within the company, but it does not replace checking the document.

No. Part II, Chapter 6.4, page 98 of the KSeF 2.0 Manual states explicitly (translated from Polish): ‘KSeF does not automatically send system notifications when a new invoice is received in the system.’ The Polish Ministry of Finance's material adds that the taxpayer's software must query KSeF and that a notification function can be introduced in the accounting software being used. The sources were checked on July 23, 2026.

The absence of an alert does not mean that the invoice has not been received in the system. In standard online mode, an invoice accepted by KSeF is available to the buyer whose NIP is indicated, while the manual links receipt of the invoice to the assignment of a KSeF number. However, the document becoming available and a message being sent to a person are two different events.

Availability in KSeF: the document may already be available to the buyer.

Notification: additional information may be sent by software that uses KSeF data.

Company action: the designated person must still check the document and route it for further processing.

The official Ministry guide recommends checking regularly whether the company has received an invoice, because this information is needed to process the document and payment. We describe the process in more detail in How to receive invoices through KSeF. Since KSeF does not send an alert, the next question is how software detects new invoices.

Authorised software queries KSeF for invoice metadata and compares the result with its saved state. KSeFGPT uses a starting point and previously identified KSeF numbers to find new items. Only after detecting a document can it start a business rule, such as sending a message or forwarding data to another system.

Data source: KSeF makes invoice information available through its API.

Synchronisation: the application retrieves data available to the entity and identifies new documents.

Action: the software starts the selected communication channel or subsequent process.

As verified on July 23, 2026, the production KSeF API 2.0 includes an operation for retrieving invoice metadata according to filters. The incremental retrieval documentation also specifies the required permission and the way results should be ordered. This information describes the technical KSeF mechanism, not a guaranteed alert time in an external application.

The delivery time is affected by at least the moment when the invoice becomes available, the synchronisation method used by the software and the operation of the selected channel. There is therefore no basis for promising one fixed delivery time for every alert. Once the source of the message is understood, it becomes possible to separate the events that are often collectively called a KSeF notification in everyday conversation.

The phrase invoice notification can describe three different situations. Keeping them separate prevents the mistaken assumption that a message for a counterparty, an internal purchasing alert and a UPO are interchangeable.

Incoming invoice: the message should route the document to the person who will start processing it on the buyer's side.

Outgoing invoice: a separate message may inform a counterparty or team that submission to KSeF was successful.

System confirmations: the status, KSeF number and UPO document successive parts of the process, but do not prove that the buyer has read the invoice.

The correct sequence for a purchasing alert is: KSeF makes the invoice available, the application detects it, a rule selects the recipient, a channel delivers the alert and a person performs the next task. None of these stages should automatically be treated as approval of the document. Separate guides explain how to check an invoice status after submission and what a UPO in KSeF confirms. Once the events have been separated, the content of a useful message can be defined.

A good alert should not be a copy of the entire invoice sent to every channel. It should quickly answer two questions: who should respond and what should they do next? The scope of the message should be tailored to the company's process, the recipient and its data-protection rules.

Document context: information that identifies the matter, such as the counterparty, amount or due date, if included in the message configuration.

Recipient: the person or group responsible for the relevant type of invoice.

Expected action: clear information on whether the document needs to be checked, approved, clarified or forwarded.

Secure access: a link to the appropriate view instead of automatically distributing the full XML or excessive data.

The elements below are design recommendations, not a promise about the fixed content of every KSeFGPT message. Their availability and scope depend on the selected process and configuration. Once the alert content has been defined, the company must still decide who should receive it.

A single shared inbox for all invoices quickly turns alerts into noise. A rule should connect the event with a condition, delivery location and next action. In KSeFGPT, the notification action specifies an email address or a configured Slack, Telegram or webhook integration.

The condition editor suggests the number of documents, invoice number and KSeF number, and also allows a custom field from the trigger data to be specified. Because the new-invoice event contains invoice metadata, an advanced rule can refer, for example, to the gross amount or seller details. However, it does not directly select a user or organisational group as the automation recipient.

Amount: a custom condition can compare the gross amount with the company's internal threshold. Such a threshold is an organisational rule, not a statutory limit.

Seller: a custom condition can identify supplier details available in the metadata and trigger a notification in the selected channel.

Multiple documents: the default workflow distinguishes one new invoice from several detected during the same check and can send a batch email.

Responsibility: a shared Slack or Telegram channel can make the alert available to the team even when one person is unavailable.

The scenarios below illustrate a process-design model, not instructions for configuring the feature. Once the recipient and next task have been defined, the boundary between a notification and an accounting decision must still be maintained.

An alert signals a technical or operational event. It does not determine whether the invoice relates to an actual company purchase, whether the data is correct, whether the expense has been approved or how the document should be recorded in the accounts. These decisions require a separate stage and a responsible person.

This distinction is particularly important when a document from an unknown seller or an invoice that does not match an order appears in KSeF. The mere fact that the system has made the document available does not confirm the commercial validity of the purchase. The guide What should you do when an invoice for a purchase you did not make appears in KSeF? explains what to do next.

A mature workflow separates document detection, owner assignment, substantive verification and the accounting decision. Automation can shorten the route that information takes to reach the right person, but it should not remove oversight where an assessment of the contract, delivery or validity of the expense is required.

There is also no basis for drawing universal conclusions from the absence of an alert about the loss of the right to deduct VAT, a missed payment deadline or a penalty. The consequences depend on the specific situation and the applicable rules. A notification should be treated as the start of document processing, not its outcome.

KSeFGPT does not wait for a push notification from KSeF, because KSeF sends no such alert. The product periodically retrieves invoice metadata, remembers KSeF numbers it has already identified and starts an automation workflow only for new documents.

After KSeF access credentials are saved, the product creates an active default notification workflow addressed to the user's email. When monitoring starts, KSeFGPT establishes a starting point so that it does not recreate alerts for older invoices. The default workflow sends an individual email for one new invoice or a batch message when more than one is detected during a single check.

Detection: KSeFGPT checks the metadata available in KSeF and compares it with its saved state.

Condition: the default rule distinguishes one invoice from several, while custom conditions can use fields from the trigger data.

Recipient: the information is sent to the configured email address, a Slack or Telegram channel, or a connected system through a webhook.

Action: the team proceeds to verification, approval, clarification or another task defined by the company.

This workflow concerns a new incoming invoice. It should not be confused with a message to a counterparty after an outgoing invoice is issued, or with a status or UPO. These are separate events and processes.

The KSeFGPT workflow view lets users monitor activity, runs and process errors without turning this article into a configuration guide. A complete overview of the available features can be found on the KSeFGPT Automation page.

How to receive invoices through KSeF - learn the difference between a document being available in the system and its subsequent processing within the company.

What should you do when an invoice for a purchase you did not make appears in KSeF? - see why a new document requires substantive verification.

How to check an invoice status in KSeF after submission - learn how to read the process result for an outgoing invoice.

UPO in KSeF - find out what a UPO confirms and how it differs from an operational alert.