Detailed changelog for Continia Document Output 2026 R2, including CDN

The CII XML structure used for ZUGFeRD and XRechnung invoices has been improved in many places, so the invoices meet the EN 16931 and XRechnung validation rules. Line discounts are now exported as line allowances, line totals are rounded correctly, and the buyer reference is included.

The invoices now also contain more details, such as payee and seller tax representative information, contact details, the delivery address, billing periods, item classifications and attributes, and references to other documents. Existing installations are updated automatically when the app is upgraded.

Receiver IDs used when sending eDocuments through the French eInvoicing network can now include a suffix, providing greater flexibility when identifying individual receiving entities. The suffix type can be configured per customer or vendor using the new Receiver ID Suffix Type field in the eDocument setup.

The functionality is extensible, allowing partners to define custom suffix types by extending the Receiver ID Suffix Type enum and implementing the IRcv Id Suffix interface. Once a suffix type is available, it can be selected for the relevant customer or vendor.

A Recalculate action is now available on the eReport Card and eReports list pages, where multiple eReports can be selected and recalculated at once. Recalculating returns the documents in an eReport to the processing queue, allowing the eReport to be rebuilt the next time Process References runs, either manually or as scheduled.

If the eReport has not been sent, its calculated data is cleared and its status returns to New. If the eReport has already been sent, the original eReport remains unchanged, and the next processing run creates a correction eReport that refers to it. Documents added manually before the processing run are also included in the recalculation.

An eReport cannot be recalculated in the following cases:

• The eReport is already prepared for recalculation and has not yet been processed.
• An unsent correction eReport already exists.
• The tax authority does not allow corrections for the report type.
• The group members have changed since the eReport was created.

The Scenario Framework can now be used with custom document tables. Previously, the eDocument Scenario Flow field was only populated and transferred to posted documents for standard Business Central sales, purchase, and service documents. When the field was added to a custom document table, the scenario flow was not transferred to the posted document.

A new public codeunit, CTS-CDNSF Scenario (6252612), has been added to the Scenario Framework, enabling extensions to:

• Set and update the scenario flow on custom document records.
• Open the Record Coding Values page for a record.
• Copy scenario values between records.
• Validate that required header and record values have been populated.
• Transfer scenario coding from unposted to posted documents during posting, consistent with standard Business Central documents.

The Scenario Flow and Record Coding Value tables and their related enums are also available to extensions.

Standard Business Central sales, purchase, and service documents are unaffected and continue to work as before.

Scenario flow handling for French eDocuments has been enhanced to ensure that invoices and credit memos contain the business process information required by the French eInvoicing platform. For sales and service invoices and credit memos sent in the UBL-FR, CII-FR, or Factur-X format, an eDocument Scenario Flow must now be selected before posting. This helps prevent documents from being rejected later because the required business process information is missing. If the eDocument Scenario Flow field is empty, posting is blocked and the following error is shown:

• The eDocument Scenario Flow must be filled in on Invoice <No.> before posting, because the document is sent in a French electronic format. If no scenario flows exist yet, set them up on the Scenario Flows page.

Documents sent in other electronic formats are not affected.

The eDocument Scenario Flow can also now be set or changed directly on the Posted Sales Invoice and Posted Sales Credit Memo pages. This allows documents that were posted without a scenario flow to be corrected without cancelling and reposting them. Selecting a scenario flow populates the corresponding scenario values and updates the customer's scenario flow history in the same way as during posting.

To protect posted documents from unauthorized changes, the scenario flow can only be changed by users with permission to modify posted documents. For other users, the field remains read-only. When the eDocument is created, the mandatory scenario values are validated in the same way as during posting.

After a line was deleted on an order used in a PEPPOL order change flow, AnticipatedMonetaryTotal was miscalculated because the deleted line was still counted, causing the following error:

• Expected total sum of line amounts MUST equal the sum of the order line amounts at order line level

This has now been fixed, and the order change can now be sent.

Previously, when discovering receiving capabilities using the eCandidates page, the FR:CTC identification type was not included in the discovery process. This could prevent receiving capabilities from being identified correctly for customers in France, where FR:CTC is commonly used.

The FR:CTC identification type is now included when discovering receiving capabilities. To ensure that FR:CTC is evaluated for existing customers, run Refresh List with Customers with Force Refresh Cache enabled.

When you sent a posted sales credit memo in the ZUGFeRD format, the following error occurred:

• There is no XML Structure Setup within the filter. Filters: Electronic Document Type: eBilling, eBilling Document Type: Credit Memo, Electronic Format: ''

The format only included a structure for invoices. It now also includes a structure for credit memos, so credit memos can be sent in this format, and incoming credit notes in this format are recognized as credit memos.

Added indirect permissions to the Continia Delivery Network - Scenario Framework app to allow for users with DO-BASIC permissions to assign eDocument Scenario Flow code (field value) to sales document.

Before this change the user would get the follow error message:

• "Sorry, the current permissions prevented the action. (TableData 6252607 CTS-CDNSF Scenario Hdr. Value eDocument Scenario Header Value Insert: Continia Delivery Network - Scenario Framework)"

Previously, when performing a lookup on the Participation field on any eDocuments Setup Card page, the following error could occur if the new eDocuments experience was disabled:

• The supplied field number '70' cannot be found in the 'Participation' table.

When an output profile both sent eDocuments through the network and attached the eDocument XML to an email, the XML attachment was missing for documents that had already been sent, and the following error occurred:

• Network Document {GUID} has already been sent.

The XML is now attached as expected, and no error is reported for this scenario.

Previously, when an invoice was exchanged with a party whose identifier included a routing suffix, such as a French SIREN with a suffix, the invoice response (CDAR) could be sent to the recipient's identifier without the suffix.

Invoice responses are now sent to the same endpoint as the invoice they respond to, ensuring that routing suffixes are preserved.

Sales prepayments can now be included in eReporting. Posted prepayment invoices are reported as document type 386, while posted prepayment credit memos are reported as document type 503.

For foreign business customers, prepayment invoices are reported in F10.1 and the corresponding payments in F10.2. For domestic consumers, prepayment invoices are reported in F10.3 and the corresponding payments in F10.4. The final invoice is reported for the remaining sales amount after deducting the prepayment.

Payments are not reported when the buyer is liable for the VAT, such as for reverse charge transactions, intra-EU supplies, and exports.

Previously, eReports were not validated against the Schematron rules before being sent. As a result, an eReport that did not meet the required format could still be sent.

Each eReport is now validated against the Schematron rules before it is sent. If validation fails, the eReport is not sent and the validation errors are logged.

Previously, in Business Central online, the Scenario Flow field could not be changed on the Posted Sales Invoice and Posted Sales Credit Memo pages, even for users with the required permission sets. This was because Business Central online only allows posted documents to be modified through the standard update process.

The Scenario Flow field has now been added to the page that opens from the Update Document action. The scenario flow can therefore be changed on posted sales invoices and credit memos in Business Central online, with the changes saved through the standard update process.

Previously, French e-reporting took the VAT exemption code from the Full VATEX Code field on the VAT Clauses page. The code is now taken from the VATEX Code field on the VAT Posting Setup page, and existing codes are copied there during the update.

Action required: For VAT Posting Setups that use a VAT Clause with a code that does not start with VATEX-, fill in the VATEX Code field manually.

Flow F10.2 now reports payments from foreign B2B customers instead of French ones. Flows F10.1 and F10.3 now also include invoices with the scenario codes USECASE-20 and USECASE-21, so prepayments and their related documents are reported again.

The filters are updated automatically when the app is updated, and manually changed filters are kept.

Previously when sending an eDocument using the French CII or Factur-X formats, the following errors could appear in the validation log:

• La mention relative aux frais de recouvrement (code PMT) est absente. Elle est obligatoire dans les notes (BG-3).
• La mention relative aux pénalités de retard (code PMD) est absente. Elle est obligatoire dans les notes (BG-3).
• La mention relative à l’escompte ou à son absence (code AAB) est absente. Elle est obligatoire dans les notes (BG-3).

Fixed a mapping issue in the CIIEN-16931 Xml Structure:

• /rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:BuyerReference is now mapped to Buyers Reference on the eBilling Header.
• /rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:ContractReferencedDocument/ram:IssuerAssignedID is now mapped to Contract No. on the eBilling Header.
  

Previously, when sending an eDocument through the PA France network, the following error could occur:

• Specification identifier MUST begin with the value 'urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0' and follow the format rules for the identifier.

This could occur when the eDocument Line Types setup was incomplete. The complete setup can now be imported using the relevant eDocuments setup guide.

Previously, when sending a corrective credit memo for France in the CII format, the issue date of the referenced invoice was formatted as YYYY-MM-DD instead of the YYYYMMDD format required by the French CII specification. As a result, the credit memo could fail validation with the following error:

• BR-FR-03/BT-26 : La date d’émission de la facture référencée (qdt:DateTimeString) doit contenir une année entre 2000 et 2099. Valeur actuelle : <Issue Date>. Veuillez vérifier la validité de la date.

The issue date of the referenced invoice is now formatted as YYYYMMDD, allowing corrective credit memos to pass French CII validation.

Previously, amount fields in French eDocuments could be generated with excessive decimal precision, resulting in an invalid document and validation errors such as:

• Le montant « 1005.800000000000000 » est invalide. Il doit : - être un nombre strictement positif (sans signe « - »), - comporter au plus 6 décimales (séparateur « . »), - contenir au maximum 19 caractères (hors séparateur). Veuillez corriger ce montant pour respecter le format requis.

Amount values are now generated with the required decimal precision, ensuring that French eDocuments comply with the required format.

When only Continia Document Output was installed, the VATEX Code field in VAT Posting Setup was hidden by default, and when it was made visible through personalization it could not be edited and had no lookup. Using VATEX codes therefore required a configuration package.

This has been fixed. The VATEX Code field in VAT Posting Setup is now visible and editable when Continia Document Output is installed.

When a sales invoice or credit memo with a line discount was exported in the ZUGFeRD or CII format, the gross price and the discount on a line were rounded separately, so the net price could differ by one cent from the gross price minus the discount, and the following validation error occurred:

• PEPPOL-EN16931-R046: Item net price MUST equal (Gross price - Allowance amount) when gross price is provided.

This has been fixed. The gross price, allowance amount, and net price are now derived from the same rounded values, so the net price always equals the gross price minus the discount. This applies to item, G/L account, and resource lines. When Prices Including VAT is enabled, the line amount is now also rounded to two decimals.

When an OIOUBL invoice that contained a prepaid amount was sent, the following validation errors occurred:

• PayableAmount is calculated incorrectly - PayableAmount ('<amount>') don't match total calculation ('<amount>')
• The sum of PaymentTerms/Amount elements or the value of the first PaymentTerms/Amount must equal PayableAmount

This has been fixed. The cac:PrepaidPayment section is now generated when a prepaid amount is specified, and the Payment Terms amount is set to match the payable amount.

Previously, when delegated users would complete the Customer Onboarding, they would receive an error that they are not allowed to schedule background tasks. This would roll back changes in Business Central and force users to resync with the backend before completing the onboarding.

This has been fixed, and delegated users can now complete the Customer Onboarding without scheduling the background job.

Added support for multiple variant criteria on a template line, so a single template can route documents on a combination of fields, such as location and department, instead of one variant field.

When a document is sent, the line matching the most criteria is used, with Priority and then line number settling ties, and a line without criteria acting as a catch-all.

Existing templates are upgraded automatically, and variant values now work regardless of the language the setup was made in.

You can read more about the new feature here: Multiple variant fields in templates

Added automatic processing of invoice responses in Document Output.

When a recipient accepts or rejects an electronic invoice sent through the Continia Delivery Network, the response is now processed automatically, and the status on the sent invoice is updated accordingly.

Rejection responses and orphaned responses are visable from the Role Center in the new cue eDocuments Requiring Attention.

You can now share a single Azure Blob container across multiple companies in Document Output by storing each company’s blobs in its own folder, matching Document Capture’s layout.

Existing setups are unaffected and keep the current flat layout with no data moved.

Added a new Automations section to the Document Output Setup page, where you can enable or disable Document Output's background jobs and see their current status without leaving the setup page.

The section covers the email queue, customer statement, and invoice response jobs.

Receiver IDs used when sending eDocuments through the French e-invoicing network can now include a suffix, providing greater flexibility when identifying individual receiving entities. The suffix type can be configured per customer or vendor using the new Receiver ID Suffix Type field in the eDocuments setup.

The functionality is extensible, allowing partners to define custom suffix types by extending the Receiver ID Suffix Type enum and implementing the IRcv Id Suffix interface. Once a suffix type is available, it can be selected for the relevant customer or vendor.

The Scenario Framework can now be used with custom document tables. Previously, the eDocument Scenario Flow field was only populated and transferred to posted documents for standard Business Central sales, purchase, and service documents. When the field was added to a custom document table, the scenario flow was not transferred to the posted document.

A new public codeunit, CTS-CDNSF Scenario (6252612), has been added to the Scenario Framework, enabling extensions to:

• Set and update the scenario flow on custom document records.
• Open the Record Coding Values page for a record.
• Copy scenario values between records.
• Validate that required header and record values have been populated.
• Transfer scenario coding from unposted to posted documents during posting, consistent with standard Business Central documents.

The Scenario Flow and Record Coding Value tables and their related enums are also available to extensions.

Standard Business Central sales, purchase, and service documents are unaffected and continue to work as before.

On the Unhandled Issued Reminders page, clicking the value in the Email Log column did not open the email log because the drilldown link was inactive.

This has been fixed, and the Email Log value now opens the Document Output Log filtered to the selected issued reminder.

When using Move up on the first entry or Move down on the last entry in Email template recipient setup, an error occurred.

These actions are now handled correctly so no error occurs at the top or bottom of the list.

When Do not send if negative balance was enabled, automatic due date statements were sent to customers with negative balances.

This has now been fixed, and the customer balance is checked before sending due date statements to match the behavior of automatic period statements.

Previously, when discovering receiving capabilities using the eCandidates page, the FR:CTC identification type was not included in the discovery process. This could prevent receiving capabilities from being identified correctly for customers in France, where FR:CTC is commonly used.

The FR:CTC identification type is now included when discovering receiving capabilities. To ensure that FR:CTC is evaluated for existing customers, run Refresh List with Customers with Force Refresh Cache enabled.

Previously, when performing a lookup on the Participation field on any eDocuments Setup Card page, the following error could occur if the new eDocuments experience was disabled:

• The supplied field number '70' cannot be found in the 'Participation' table.

Previously, when an invoice was exchanged with a party whose identifier included a routing suffix, such as a French SIREN with a suffix, the invoice response (CDAR) could be sent to the recipient's identifier without the suffix.

Invoice responses are now sent to the same endpoint as the invoice they respond to, ensuring that routing suffixes are preserved.

Previously, eReports were not validated against the Schematron rules before being sent. As a result, an eReport that did not meet the required format could still be sent.

Each eReport is now validated against the Schematron rules before it is sent. If validation fails, the eReport is not sent and the validation errors are logged.

Previously, in Business Central online, the Scenario Flow field could not be changed on the Posted Sales Invoice and Posted Sales Credit Memo pages, even for users with the required permission sets. This was because Business Central online only allows posted documents to be modified through the standard update process.

The Scenario Flow field has now been added to the page that opens from the Update Document action. The scenario flow can therefore be changed on posted sales invoices and credit memos in Business Central online, with the changes saved through the standard update process.