KSeF changes not only the way invoices are issued and received. From 1 January 2027, new requirements will also affect payment processes.
For certain payments between active VAT taxpayers, it will be necessary to provide either the invoice KSeF number or an Aggregate Identifier assigned by KSeF. For organisations using Microsoft Dynamics AX 2012, this means connecting KSeF data with another ERP area: payments, bank statements and settlements.
The KSeF Aggregate Identifier is particularly important because it allows a single payment to be linked to multiple invoices that have KSeF numbers.
Retcon has developed an extension for Microsoft Dynamics AX 2012 that supports this process both for outgoing payments related to purchase invoices and incoming payments related to sales invoices.
The KSeF Aggregate Identifier is an aggregating number that can be generated in KSeF for at least two structured invoices issued by the same seller.
To generate it, the KSeF numbers of the invoices to be included must be provided. This makes it possible to use one identifier for a payment covering multiple invoices instead of listing each individual KSeF number separately.
KSeF also allows the Aggregate Identifier to be decoded, meaning that it is possible to determine which invoice KSeF numbers are associated with it. It is also possible to check which Aggregate Identifiers contain a specific KSeF number.
The Aggregate Identifier consists of 35 characters. Its structure includes:
Example structure:
9999999999-IZ202704-FFFFFFFFFFFF-FF
According to the Polish Ministry of Finance, a single Aggregate Identifier can cover between 2 and 10,000 invoices. All invoices must have a KSeF number and must relate to the same seller.
From 1 January 2027, an active VAT taxpayer making a payment for invoices covered by the relevant regulations to another active VAT taxpayer will be required to provide either a KSeF number or an Aggregate Identifier if the payment is made by bank transfer or another payment instrument that allows a payment reference to be entered.
For:
The requirement will also apply to relevant payments made by third parties. The changes also affect payments made under the split payment mechanism.
For businesses, this means that ERP integration with KSeF no longer ends with issuing or receiving an invoice.
The process can be represented as follows:
invoice → KSeF number → payment → Aggregate Identifier → settlement
KSeF data therefore begins to directly affect banking and accounts receivable/accounts payable processes.
A company has received four structured invoices from one supplier. Each invoice has been accepted by KSeF and has its own KSeF number.
The company wants to settle all four liabilities with one bank transfer.
Instead of handling four KSeF numbers separately, the buyer selects the invoices for which an Aggregate Identifier should be generated. KSeF then creates one identifier covering the selected documents.
This identifier can subsequently be used when making the combined payment.
The Polish Ministry of Finance describes an equivalent scenario in the official KSeF 2.0 manual: the buyer receives several e-invoices from the same seller, provides their KSeF numbers, generates an Aggregate Identifier and then uses it when making the payment.
For invoices to be included in one Aggregate Identifier:
One invoice may be assigned to more than one Aggregate Identifier. The Ministry of Finance identifies partial payments as one example of such a use case.
Microsoft Dynamics AX 2012 was developed many years before the introduction of Poland’s National e-Invoice System. The standard system therefore does not include native support for KSeF numbers or the Aggregate Identifier mechanism.
AX 2012 can handle payment preparation, vendor invoices, settlements and bank statements, but KSeF-specific data requires an extension of the standard processes.
Without appropriate integration, users would need to perform part of the process outside the ERP system, for example:
With a small number of documents, these activities can be handled manually. With hundreds or thousands of invoices, however, they increase the amount of work performed by finance teams and make the process more difficult to control.
Handling the Aggregate Identifier in AX 2012 requires the payment process to be connected with KSeF.
In Retcon’s solution, the mechanism is integrated with financial processes in AX 2012. The system can prepare invoice data, perform the required validations, communicate with KSeF and save the returned identifier against the relevant documents.
As a result, users do not need to move the entire process to a separate application.
For purchase processes, the starting point is posted vendor invoices that have KSeF numbers.
The user prepares a payment in Microsoft Dynamics AX 2012. Invoices selected for payment can be grouped according to the conditions required to generate an Aggregate Identifier.
Before sending the request to KSeF, the system should verify in particular:
After successful validation, the KSeF numbers of the relevant invoices are submitted to KSeF.
KSeF generates the Aggregate Identifier, which can then be stored in AX 2012 and used in the subsequent payment process.
In financial processes, not all documents included in a payment journal should always be handled in the same way.
For this reason, Aggregate Identifier handling can support two scenarios.
In automatic mode, the system analyses the documents and creates appropriate groups of invoices that meet the process requirements.
In manual mode, the user selects the documents for which the Aggregate Identifier should be generated.
This approach allows companies to automate high-volume processes while retaining user control over non-standard cases.
The Aggregate Identifier is also relevant when the company acts as the seller and receives payment from a customer.
Example:
A company has issued 10 invoices of PLN 1,000 each to one customer. The customer pays all invoices with one transfer of PLN 10,000 and uses an Aggregate Identifier in the payment reference.
After importing the bank statement into the ERP system, the amount of PLN 10,000 alone is not sufficient to determine which invoices should be settled.
The Aggregate Identifier can be used to obtain from KSeF a list of invoice KSeF numbers associated with the identifier.
The ERP system can then use those KSeF numbers to locate the correct sales invoices.
KSeF allows an Aggregate Identifier to be decoded, meaning that the user can determine which invoice KSeF numbers are included in it.
From the perspective of Microsoft Dynamics AX 2012, the process may work as follows:
The ability to decode the Aggregate Identifier is an official KSeF functionality intended specifically to identify the invoices included in the set.
In the most straightforward scenario, the system has a complete set of data:
The system can then link one payment transaction with the appropriate set of invoices.
The KSeF number plays the key role. It acts as the link between the document stored in AX 2012 and the information returned after decoding the Aggregate Identifier.
Not every payment should qualify for automatic settlement. If data is missing or inconsistencies occur, a safer scenario is to route the transaction for user verification.
The process should also cover exception scenarios.
For example:
In such cases, the system should not automatically settle invoices that cannot be identified unambiguously.
Automation should handle repetitive and unambiguous scenarios, while exceptions should remain subject to user review.
One invoice may be used in more than one Aggregate Identifier.
This is relevant for partial payments. An invoice may be included in one set during the first partial payment and then used again in another Aggregate Identifier during the next settlement.
For this reason, the ERP system should be able to retain the history of relationships between the invoice, its KSeF number and subsequent Aggregate Identifiers.
The Polish Ministry of Finance confirms that one invoice may be assigned to more than one Aggregate Identifier, including in scenarios involving partial payments.
In financial processes, it is important not only to perform the operation but also to be able to determine later what happened between the ERP system and the external platform.
For this reason, an AX 2012 integration with KSeF should record the communication history related to Aggregate Identifiers.
The recorded information may include:
This makes it easier to diagnose issues and reconstruct the process during a subsequent review or audit.
The changes also apply to the split payment mechanism.
From 1 January 2027, the requirement to provide the KSeF number also applies to relevant payments made under the split payment mechanism.
If the payment covers several selected e-invoices, the payment reference may include an Aggregate Identifier generated by KSeF. Official materials indicate that, in this context, the payment may cover invoices from one supplier for a period of no less than one day and no more than one month.
This distinction is important: the one-month limitation relates to the described split-payment process and should not be presented as a general rule governing the Aggregate Identifier itself.
The requirement relating to the KSeF number and the Aggregate Identifier in payment processes will apply from 1 January 2027.
Preparation should start earlier.
The integration does not involve simply adding one new field to AX 2012. It affects the entire process:
invoice → KSeF number → document selection → Aggregate Identifier generation → payment → bank statement import → Aggregate Identifier decoding → settlement
Before production deployment, companies should therefore test both standard payment scenarios and exceptions such as partial payments, missing KSeF numbers and incorrect identifiers.
No. AX 2012 was developed before KSeF was introduced, so the standard version of the system does not contain a mechanism for handling the Aggregate Identifier. An extension of the system and integration with KSeF are required.
No. Each invoice continues to have its own KSeF number. The Aggregate Identifier aggregates the KSeF numbers of several invoices and allows them to be linked to one payment.
No. The Aggregate Identifier is intended for at least two invoices. For a payment covering a single invoice, its individual KSeF number is used.
One Aggregate Identifier can include from 2 to 10,000 invoices.
No. All invoices included in one Aggregate Identifier must relate to the same seller.
Yes. This is possible and can be used, for example, for partial payments.
Yes. KSeF allows users with the appropriate permissions to determine which invoice KSeF numbers are included in a specific Aggregate Identifier.
An Aggregate Identifier may be generated by an entity with the appropriate rights to access the invoices. This may include the issuer or the recipient of the invoices.
The relevant requirements will apply to payments made from 1 January 2027.
Yes. Retcon’s solution for Microsoft Dynamics AX 2012 supports the use of the Aggregate Identifier in outgoing and incoming payment processes and integrates AX 2012 with KSeF communication.
Implementing KSeF does not end with sending sales invoices and receiving purchase invoices.
From 1 January 2027, the KSeF number and the Aggregate Identifier will also become directly relevant to payment processes.
For organisations still using Microsoft Dynamics AX 2012, this means extending the system with mechanisms that enable KSeF data to be used in payments and settlements.
Retcon’s AX 2012 solution supports the Aggregate Identifier in both purchase and sales processes, integrating KSeF communication with financial processes carried out in the ERP system.
Polish Ministry of Finance – “KSeF number and Aggregate Identifier”
Official information on the rules for generating, structuring and using the Aggregate Identifier.
Polish Ministry of Finance – “KSeF 2.0 Manual, Part III – Additional KSeF functionalities”
Detailed rules for generating the Aggregate Identifier, limits and example payment scenarios.
Official KSeF 2.0 API documentation
Technical documentation covering communication with the National e-Invoice System.
