Resolved issues

The system rejected some retrieved invoices when the delivery location identifier was always treated as a GLN number, even when the supplier had provided a different (valid) type of identifier.

The system now recognizes the actual type of the delivery location identifier, and GLN validation is only applied to genuine GLN numbers.

The system rejected retrieved invoices when the attachment's MIME type could not be determined (missing or generic application/octet-stream type), causing the PDF processing to fail.

The system now correctly derives the MIME type from the file extension.

The system rejected retrieved invoices without a Due Date because this field was mandatory by default in any recipient profile unless explicitly edited.

Due Date is no longer mandatory by default in recipient profiles.

The mapping has been corrected so the block is created whenever a due date is present. DueDate delivery no longer depends on the optional payment terms note.

Previously, when a member requested activation of production services (production clearance, retrieval, e-reporting) or publishing of production endpoints, and the request failed on the tax authority side, the failure response could cause the member's previously entered KYC contact details to be overwritten with empty values — leaving the KYC form on the UI blank.

Endpoint publishing to the PEPPOL directory now completes reliably.

This also resolves an error when searching for such messages in the message log.

Resolved an issue where a French domestic invoice submitted through the Pre-Production API was rejected with "The electronic recipient could not be identified and a print service is not used" - even though the invoice was valid and should have been routed to the French platform. The problem occurred when the recipient was not present in the TeC Registry.

This has now been fixed, and such invoices are correctly routed to the French platform.

Self-billing invoices were previously exported using the same logic as standard Accounts Payable (AP) invoices, causing data inconsistencies and incorrect states in the customer's ERP system (since a self-billed invoice is issued by the buyer on behalf of the supplier, not by the supplier itself).

As a first step, self-billing invoices are now filtered out and excluded from the general AP invoice export flow, via FTP, Email, and API. This also applies to the API used for retrieving received invoices - self-billing invoices are now excluded by default when fetching all AP invoices.

A dedicated export flow and configuration for self-billing invoices, ensuring correct mapping to the ERP, is planned as a follow-up release.

Resolved an issue where invoices could not be sent to a member that had more than one receiving endpoint configured (e.g. a SIREN_SUFFIX endpoint in addition to the published SIREN endpoint). Sending would fail with the error: "[Member] has more than one electronic address. A unique address (identifier) for each recipient must be provided to deliver the invoice."

Invoices can now be delivered correctly to accounts with multiple receiving endpoints.

The correct status icon is now shown for invoices in this state.

Resolved an issue where a self-billing invoice was shown as 'Sent' in the submitter list even though it was never delivered to the recipient. In these cases, delivery failed with the error "Settings for sending incorrect or missing", but the status did not reflect the failure.

The status now correctly reflects the outcome, and the sender receives a negative response from the Peppol loop when delivery fails. In addition, the recipient of a self-billing document is no longer required to have sending settings enabled, since they are the receiving party - removing the incorrect send-settings validation that caused the failure.

Resolved an issue where the Parent (head office) row in the "Electronic addresses" table displayed the entity's SIRET (e.g. 98765432400019), suggesting a SIRET-level (establishment) the endpoint was being published for the head office.

In reality, TeC publishes the parent endpoint at SIREN (legal-entity) level, not SIRET - so the displayed identifier did not match what was actually registered.

Resolved an issue where long company names were truncated on TeC-generated PDFs. The supplier name was cut at 42 characters (with a trailing "…"), and in the footer the name and address were cut even shorter at 23 characters.

Long company names now fit and display in full on the generated PDF.

Invoices retrieved from KSeF that fail validation against the recipient's profile can now be viewed and edited prior to acceptance.

The original received invoice (XML created by KSeF) is stored in its original and unchanged format.

Tungsten e-Invoice Connect. generated PDF for KSeF clearance invoices was missing required KSeF invoice data, resulting in an incomplete invoice representation. As a workaround, the Tungsten e-Invoice Network (TeN) generated PDF was used instead, as it contained the full set of required data including the KSeF QR code.

For cross-border outbound invoices, the generated PDF included FA3 XML data that is not relevant to non-Polish suppliers, resulting in a confusing invoice representation.

OIOUBL invoices and credit notes received via NemHandel that referenced an external UtilityStatement failed to process correctly. Affected files were not delivered to the destination and remained stuck in the source folder without an error notification. The issue occurred because the filenames generated during processing exceeded the maximum supported file path length, causing the rename and move operations to fail silently.