What should companies running Infor M3 prepare for successful KSEF implementation?
- mmel92
- Mar 28
- 5 min read
Updated: Apr 2

For a successful implementation of Krajowy System e-Faktur (KSeF) in Infor M3, companies should prepare across various technical, operational, and compliance aspects. Below is a detailed list of steps to guide the preparation for issuing outgoing invoices:
1. Understand KSeF Requirements and Regulations
Review KSeF Requirements: Ensure that your company is well-versed in the legal requirements for electronic invoicing in Poland, as mandated by the Polish Ministry of Finance. From February 1st 2026 taxpayers must use the centralized platform via the National System of e-Invoices, Krajowy System e-Faktur (KSeF), to issue and receive their invoices in electronic form in a defined XML format. This will replace the existing SAF-T (JPK-FA) monthly reporting. KSeF does not automatically send the invoices to customers, customers must download the e-invoices from the KSeF portal.
2. Evaluate Current Infor M3 Configuration
Check Infor M3 Version Compatibility: Make sure that the Infor M3 version is compatible with the latest KSeF integration module. Infor does not provide support for versions older than 13.4. If you are using an earlier version of Infor, we recommend integration of Infor with 3rd party tools, which are abundant on the market. For stability of solution, experience of the team we propose Compass KSeF: https://crido.pl/compass-ksef/
3. Integration with KSeF
Prepare for integrating Infor M3 with the KSeF. This includes configuring necessary endpoints, handling authentication, and ensuring secure data exchange.
Test Environment Setup: Establish a test environment to simulate interactions with KSeF. This allows for thorough testing of the integration before it goes live. To test KSeF in the TST environment within Infor M3, it is necessary to generate and upload certificates to the Web Services Gateway. These certificates can be generated using OpenSSL.
Digital Signature and Authentication: KSeF requires a digital signature for each electronic invoice. Ensure that the correct certificates and authentication credentials are set up in your system for secure communication with KSeF. In the PRD environment, an electronic seal will be required.
KSeF solutions for the M3 system
M3 Business Engine (M3BE)
This section defines the generic and country-specific settings for electronic invoicing to generate the proprietary file, covering various invoicing functions like customer, project, maintenance, service orders, fixed asset sales, manual, and internal invoices.
After invoices are created through different M3 Business Engine processes, several tables are updated, as shown in 'Invoice Header. Open' (CMS500). When the status reaches 80, the Financial Business Message (FBM) M3FBM_PL_Out_eInvoicing_KSEF_2024 is triggered in Infor Enterprise Collaborator (IEC), generating an .xml output.
If changes are needed after the invoice is created, the e-invoice can be recreated in 'Invoice Header. Open' (CMS500), changing the status to 90, indicating a reissued FBM output. Invoices excluded from KSeF generate a .txt file with a message stating, "This invoice 'invoice number' is exempted."
Infor Enterprise Collaborator (IEC)
This process generates the required proprietary document in an electronic format, following the Polish government’s schema, using the outbound Financial Business Message (FBM) map.
It also handles response files from the tax authority to update invoices and upload government information to M3 through the inbound FBM map.
LSP Direct is used for sending e-invoices to the tax authority. A generic outbound IEC mapping, M3FBM_LCLFileTransferOut, creates the LCLFileTransferOut BOD, which facilitates transferring e-invoices directly to the tax authority. This BOD carries the proprietary file in XML format, base64-encoded.
Once LSP Direct receives a response from the KSeF portal, it wraps the response in the LCLFileTransferIn BOD (in base64) and sends it back to ION for M3 to process. The LCLFileTransferIn BOD may contain either a successful transmission response from KSeF or a <SystemResponse> indicating an error with the third-party API or LSP's web services setup. A generic inbound IEC mapping, M3FBM_LCLFileTransferIn, is used to decode the response. After decoding, the invoice is updated with the government’s status and information via M3FBM_PL_In_ProcessResponse_KSeF_FA2 using INVBODMI. These updates can be viewed in ‘Invoice Header. Open’ (CMS500) in Cloud version and AAS390 in 13.4 version and ‘E-invoice Government Information’ (CMS516) - Cloud version and AAS390 - 13.4 version.
Localization Services Platform (LSP)
This manages the connectivity via LSP Direct, allowing M3 already capable of generating the proprietary format to utilize the LSP connector through the LSP web services gateway. This enables direct submission of electronic invoices from M3 and receipt of responses. It’s important to note that LSP Direct does not verify the contents of the proprietary file.
4. Validate KSEF Response
Check the response from KSEF after submission. The response should indicate whether the invoice was successfully processed or rejected. The response should indicate successful submission, along with the unique KSEF invoice ID. The ideal scenario is when the system successfully communicates with KSeF, the invoices pass all validation checks, and there are no issues with connectivity, business logic, or interoperability. Each step in the process occurs smoothly, ensuring the invoice is submitted, processed, and accepted without errors. While we strive to ensure a smooth integration between KSeF and Infor M3, it’s important to be aware that various technical, business, or process issues (unhappy flows) may arise during the submission and processing of invoices. Below are some potential challenges that could occur:
Technical/Connectivity Issues:
KSeF may experience unavailability or downtime, resulting in failed invoice submissions.
Communication timeouts or network connectivity issues could interrupt the process.
Authentication failures or incorrect certificates could prevent successful invoice submission.
Business/Validation Errors:
Invoices may fail schema validation due to missing or invalid data (e.g., incorrect VAT number, missing mandatory fields).
KSeF may reject invoices due to logical errors, such as mismatched totals or incompatible VAT rates.
Duplicate invoices or incorrect references to base invoices could cause processing issues.
Interoperability & Process Challenges:
The buyer may face issues retrieving invoices if their system isn’t configured to properly fetch them from KSeF.
Correction invoices could be rejected if they don’t align with the original invoice.
Delays in receiving invoices could occur due to processing backlogs or polling delays.
LESSONS FROM ITALY (FatturaPA / SDI)
Italy faced similar issues early on:
Massive rejections at the start due to formatting mismatches.
Frequent schema updates caused integration failures.
Authentication issues with intermediaries (authorized channels).
Performance slowdowns at month-end due to high traffic.
Confusion with document statuses — “delivered” by SDI ≠ “accepted” by recipient.
In the next article we'll describe overview and potential preparations for incoming e-invoices in Poland.
Lightning ERP offers comprehensive solutions to monitor and manage unhappy flows effectively. Our dashboard is designed to track any issues that may arise during the process, ensuring swift detection and resolution among thousands or more invoices to maintain seamless operations. Dashboard is design to quickly review and filter various invoice statuses based on invoice integration status from CMS500. Upon clickingn on invoice list will redirect to the CMS500 transaction. That's one of convenient ways to control correctness of this integration, leveraging modern Infor technology.

Author: Magdalena Meloch, mmel@lightning-erp.com
Comentarios