E-invoices at the Finance Center

KSeF was one of the largest compliance projects in recent years. It required changes to systems, processes, integrations, procedures, and often to the day-to-day organization of work in finance and accounting departments. Right up until the final weeks before launch, companies were grappling with regulatory uncertainty, technical changes, testing, user questions, and the need to prepare contingency plans.

Today, we can say that the first and most difficult stage is behind us. Starting February 1, 2026, the largest taxpayers—and starting April 1, all other entities—are required to issue invoices via KSeF. The systems have been launched, the processes are up and running, and structured invoices—sent to and retrieved from KSeF—have become part of everyday life.

It was an intense time for us as well. More than 120 customers are using the All for One KSeF solution to process structured invoices in SAP. In the first two months, 4.5 million invoices passed through our solution. With 87 million invoices nationwide, this means that during the initial period, we processed every twentieth invoice in Poland. What matters most, however, is not the numbers themselves, but the stability of the process: sales invoices are sent, purchase invoices are received, UPO documents are processed, and SAP systems are integrated with the ministry’s platform.

This doesn’t mean the KSeF issue can be shelved. On the contrary—the next phase is just beginning. It’s less spectacular than the implementation of the requirement itself, but from the perspective of financial efficiency, it’s often much more important. Now that the electronic invoice is already in the system, the question arises: what’s next? How can it be used not only to meet legal requirements, but also to truly streamline and automate finance operations?

KSeF is just one element of a broader shift toward digitizing transaction reporting and documentation. Another major requirement for finance departments is JPK_CIT, the new system for reporting tax and accounting data. In practice, this means that SAP systems must be prepared to support the JPK_KR_PD structure, which covers accounting ledgers, and the JPK_ST_KR structure, which pertains to fixed assets and intangible assets. The official tax website lists JPK_KR_PD and JPK_ST_KR as two of the five JPK_PD structures.

In the first reporting year, the deadline was extended to the end of July 2026, which provided a few extra months for additional preparations, both on the part of the administration and the providers of integration solutions, as well as, of course, the companies themselves. Organizations are currently in the midst of an intense preparation period: analyzing source data, verifying the chart of accounts, assigning tags, filling in missing information, checking fixed asset records, testing reports, and preparing the technical submission of files.

This is a difficult task because the regulations are ambiguous, and their practical implications are far-reaching. One need only look at the number of questions and answers published by the Ministry of Finance to see how many issues taxpayers have raised as requiring clarification. Issues that often arise include account codes, the consistency between synthetic and analytical accounts, the date of a business transaction, the completeness of fixed asset data, and the technical size of JPK files.

At All for One, we address these challenges with our All for One JPK solution, through which we support the adaptation of SAP systems to the new requirements. Our offering includes an SAP system readiness audit, the implementation of necessary changes, and the deployment of the JPK_KR_PD and JPK_ST_KR structures, along with their adaptation to the client’s specific accounting requirements. Already, 150 companies are preparing to generate these new structures using our tool.

JPK CIT projects are more than just preparing SAP to generate another report. They are an audit of the quality of accounting and tax data in the system. And at the same time, they are further proof that the digitization of finance goes beyond mere compliance with legal requirements.

As the dust begins to settle following the implementation of KSeF and preparations for JPK_CIT, many companies come to the same conclusion: legal compliance has been ensured, but the process of handling purchase invoices still requires work.

Electronic invoices reach the organization quickly, in a structured format, and through a predictable channel. This is a huge qualitative change. Until now, information often had to wait for the invoice: the order, receipt, approval, and documents confirming service completion. Today, the situation is reversed. The invoice arrives almost immediately—and it is the invoice that waits for the information: who is responsible for the expense, which purchase order it is associated with, whether the service has been performed, where the attachments are, and who should approve it.

Integration with KSeF does not answer these questions. KSeF delivers the invoice, assigns it a number, and ensures formal compliance and a uniform format. But it does not know who in the organization ordered the service. It will not indicate whether the invoice relates to a specific project. It will not indicate that an acceptance report or a shipping document is required for settlement. It will not replace the cost approval process. It will not automatically assign accounting entries in accordance with the company’s internal policies.

Therefore, the e-invoice should become the centerpiece of the financial process, rather than merely a document downloaded from the ministry’s platform.

When it comes to purchase invoices, it is essential to integrate KSeF with the subsequent document processing workflow. In the All for One solution, the starting point can be the KSeF Purchase Invoices dashboard, which allows you to import purchase invoices from KSeF into SAP and forward them—to the FI or MM modules, to an internal workflow, to an external document management system, or to the Rockawork platform.

This is important because companies are at different stages of digital transformation. Some have a sophisticated invoice workflow, some use SAP workflows, some rely on third-party solutions, and some still base their processes on manual tasks. In practice, there is no single universal model for processing purchase invoices. However, it is possible to establish a common logic: an invoice from KSeF is routed to a central dashboard, where it is identified, linked to the appropriate process, and then forwarded to where users actually work.

For some organizations, the optimal solution will be electronic purchase invoice workflow in Rockawork—a modern, browser-based low-code platform that can be integrated with OCR and a transactional system, such as SAP. For others, a traditional solution within the SAP system, based on the MIRO transaction process, will be more appropriate. Still other companies may prefer to use their own workflow tool or a solution from another vendor.

The most important thing is that an e-invoice doesn’t just sit in the dashboard as yet another document to be manually transcribed. Its value only becomes apparent when it triggers the subsequent process: approval, account assignment, receipt verification, posting, archiving, and reporting.

One of the most common issues with purchase invoices is identifying the person responsible for the expense. In many cases, the process is straightforward. If the invoice includes an order or requisition number, the system can link it to the corresponding document. If it involves a regular supplier, the approval process is usually known. If a similar invoice appears on a recurring basis, you can use the history of interactions with the supplier.

But there’s still a fourth group: “everything else.” One-time invoices, business trip expenses, parking fees, minor service purchases, team-building event costs, unplanned services, and ad hoc purchases. These are documents that appear randomly within an organization and often lack a clear point of reference.

In such cases, the accounting department investigates: who might have incurred the expense, which department the invoice pertains to, and whether anyone can confirm the validity of the expense. This investigation takes place via email, Teams, phone, and sometimes literally by “walking around the office.” Identifying a single invoice like this often takes several to over a dozen minutes. On a larger scale, this becomes a significant operating cost.

The solution may be an expense reporting process. An employee who has incurred an expense does not need to know accounting accounts or the rules for posting entries. All they need to do is enter basic information (a few details, or sometimes just one) into a simple form: the amount, date, supplier, tax ID number (if applicable), and a brief description. This information is entered into the system and awaits the invoice, or vice versa: an invoice from KSeF awaits matching with the expense report. The accounting department no longer has to search for the person responsible for the expense; instead, it simply links the two elements of the process.

It’s a minor organizational change, but it has a big impact: fewer emails, less confusion, faster approval, a complete audit trail, and better cost control for managers.

The second issue that KSeF highlighted very quickly is attachments. In the traditional model, an invoice was usually sent to a company via email along with a set of documents: a delivery receipt, a waybill, a service confirmation, a photo from the service call, a specification, or any other file necessary for approval. Currently, the invoice arrives via KSeF, while its business context is delivered through a different channel.

Yes, KSeF 2.0 does allow for the submission of invoices with attachments, but this is an additional feature that is not available by default to all taxpayers. If an attachment needs to be sent to the other party in a transaction, this is done outside of KSeF. In practice, this means that many companies still have to handle attachments through a separate process.

At All for One, we develop solutions that allow attachments to be linked to invoices—both on the Rockawork side and directly in SAP. A supplier can send an email with attachments and the KSeF number in the subject line or body. The system scans the inbox, recognizes the invoice number, downloads the files, archives them, and links them to the correct document. If the match is unambiguous, the process can run automatically. If not, the user receives a suggestion and confirms the link manually.

The end result is simple: the invoice, the XML file from KSeF, the preview, and all accompanying documents are all in one place. This is important not only for approval and accounting, but also for future audits. After a few months or years, the company can verify who approved the expense, on what basis, with what attachments, and as part of which process.

KSeF has introduced a new, very important identifier into the system: the KSeF number. This is a unique number assigned to an invoice by the system upon its receipt; the number is returned in the UPO and does not itself constitute part of the XML file. From the perspective of financial systems, however, it becomes a key attribute of the document.

That is why it is important for the KSeF number to be available wherever users work: in the header of an accounting document, in document lists, in SAP GUI transactions, in Fiori applications, in reports, in workflows, in the archive, and in the payment process. At All for One, we have been developing our own KSeF ID field in SAP for two years, which supports both sales and purchase invoices. It can be viewed, among other places, in accounting documents, receivables and payables lists, and in conjunction with the KSeF dashboard.

In practice, it often turns out that adding a KSeF ID field paves the way for further improvements. Since we’re expanding the accounting document, we might as well add the date of the business transaction—which is missing in standard SAP ECC—or extend the document reference if the standard field isn’t long enough. Such changes are not an end in themselves, but a response to the needs of finance users.

The Polish KSeF is part of a broader trend. E-invoicing is becoming the standard in an increasing number of countries, and companies operating internationally must consider not only the Polish ministerial platform but also document exchange in other jurisdictions.

In this context, PEPPOL—an international network for the exchange of electronic documents—plays a significant role. All for One is officially PEPPOL-certified and develops solutions that enable e-invoicing even outside of the Polish KSeF system. This is particularly important for corporate groups, companies with multiple subsidiaries, and organizations that use several financial and accounting systems.

Not all business operations run on a single SAP system. Sometimes, a group also uses non-SAP systems, which means there is a need to integrate multiple data sources. It is sometimes necessary to integrate these KSeF satellite systems to send and receive invoices and UPO documents, as well as to visualize and transfer data. Our solution provides this capability through the All for One KSeF Hub platform, which communicates directly with the ministry’s gateway and can also process data from the company’s other financial and accounting systems.

For companies using SAP Cloud ERP (SAP S/4HANA) in the Public Edition, the natural solution for e-invoicing is SAP Document and Reporting Compliance, or SAP DRC.

However, experience shows that simply retrieving an invoice from KSeF into DRC does not always mean the process is fully automated. This is where a gap arises: the invoice is available in DRC, but transferring the data to the system for posting requires user intervention. All for One’s solution is Invoice Buffer, a component that automates the transfer of data from DRC to a pre-entered document, supports OCR data processing for invoices outside of KSeF, and enables a simple workflow between the accounting department and the subject-matter expert.

This is a good example of thinking of e-invoicing not as a single feature, but as part of the overall process. The system standard is the starting point. It is only when it is integrated into users’ daily work that it delivers business value.

Another challenge is already on the horizon. Starting in mid-November 2026, companies should be ready to process new payment formats compliant with the ISO 20022 standard, and starting January 1, 2027, when paying invoices from KSeF, companies will be required to provide either the KSeF invoice number or a collective payment identifier.

For companies using SAP, this means they will need to adapt their bank file formats, the data sent to banks, and the way KSeF numbers or collective payment identifiers are handled in the payment process. This is a separate topic and a separate project, but it’s worth noting its connection to e-invoicing: the KSeF number, which is currently an attribute of the document, will tomorrow become an element of payments and settlement reconciliation.

KSeF has forced companies to digitize their invoices. JPK_CIT is forcing them to organize their accounting and tax data. ISO 20022 and KSeF payment identifiers will take digitization a step further—into the realm of payments and banking.

But the greatest value does not lie in simply fulfilling one’s obligations. It lies in what the company does with the organized, electronic document.

An e-invoice can only be a file downloaded from the ministry’s system. It can also serve as the backbone of the financial process: from document receipt, through cost owner identification, linking to the purchase order, handling attachments, approval, account assignment, posting, archiving, reporting, and payment.

This second scenario requires more than just technical integration. It requires viewing the invoice as a medium for information about the entire transaction. It requires linking SAP, workflow, KSeF, OCR, archiving, reporting, and payments into a single process. It also requires flexibility, because every organization has its own structure, its own approval paths, its own exceptions, and its own ways of working.

Therefore, following the implementation of KSeF, the relevant question is not “Are we in compliance with the regulations?” but rather, “How can we best take advantage of the opportunities offered by electronic invoicing?”

Because real change doesn’t begin when an invoice enters the system. It begins when the invoice ceases to be just a document to be processed and instead becomes the starting point of an automated, transparent, and controlled financial process.