Detailed changelog for Continia Document Capture 2026 R2 incl. CDN

A new option, Generative AI, has been added to the Line Recognition Method field on the template card. When selected, the document is sent to a generative-AI model, which extracts line values – as well as header field values, if the new Capture Header field on the template card is enabled. The extracted values are populated into the header and line fields, allowing field rules, validation, and registration to work as they do for other captured documents.

Generative-AI capture runs automatically when a document is captured, but can also be started manually from the document card using the Run Generative- AI Capture action. When started manually, additional instructions can be provided for the capture. Instructions for the AI model can also be configured at the company level, using the Company Instructions field on the Document Capture Setup page and on individual templates using the Custom Instructions field. The Maximum Pages field on the template card determines how many document pages will be processed by the AI.

While Generative-AI capture is running, the document cannot be modified. The progress is displayed in the Generative-AI Capture Status field, and each capture run is recorded in the Generative-AI Capture Logs.

For more information, see Generative-AI capture.

The OnAfterBuildApprovalEntriesForUser event is now always raised when the Purchase Approval Entries and Purchase Contract Approval Entries pages build their lists of approval entries.

Previously, the event was only raised for approvers with approval sharing configured, preventing extensions from adding approval entries for approvers without shared approvals. This change allows extensions to add custom approval entries to the lists for all approvers, including those without shared approvals.

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 message 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.

eDocuments sent in other electronic formats are not affected. The eDocument scenario flow can now also 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. When the eDocument is created, the mandatory scenario values are validated in the same way as during posting.

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.

This 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. When 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, as well as their related enums, are also available to extensions. Standard Business Central sales, purchase, and service documents are unaffected.

Previously, the business process code reported in F10.1 was only taken only from the scenario framework, and B1 was reported for every document the configuration did not cover – which was incorrect for service and mixed invoices.

A scenario framework value is still used when one is set, but otherwise the code is now calculated from the document: B1, S1 or M1 for goods, services or a mix; and B4, S4 or M4 for a final invoice that settles an earlier prepayment. If the document does not hold enough information to determine the code, B1 is used and noted in the report log.

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.

Previously, opening the Continia AI Capabilities page could fail with the following error:

• The length of the string is <Length>, but it must be less than or equal to 20 characters. Value: <Status>

This occurred when a capability had the status Setup required in a language where the translated status exceeded 20 characters, such as German, Spanish, Portuguese, or French. The page now opens correctly in all languages.

Previously, importing an XML document from the Display Documents page could result in the following error if Auto Move to Company was enabled for the document category and the document was moved to another company during import:

• JIT loading of field(s): 'XML Master Template No.' failed for table: 'Document' identification values: 'No.='

Previously, the Recognize Fields action started AI header suggestions even when the document's Line Posting Description field was empty. This resulted in unnecessary processing time and could produce low-confidence suggestions.

AI header suggestions are now skipped when the description field is empty, consistent with the behavior of the Header Suggestion action. When a posting description is available, the existing behavior remains unchanged.

Previously, opening a purchase document or a purchase document list, such as the Purchase Invoices page, could trigger the following error if the document contained an item charge without a value in Gen. Prod. Posting Group:

• "Gen. Prod. Posting Group must have a value in Item Charge: No.=<No.>. It cannot be zero or empty."

The amounts displayed by Document Capture on purchase document pages are now calculated without checking or updating the item charge lines. However, the Gen. Prod. Posting Group is still required when the document is posted.

Previously, when opening a page containing the Documents FactBox (e.g.: the Vendor Card page), the following error could occur if the number contained special characters such as (, ), or &:

• The length of the string is , but it must be less than or equal to 20 characters. Value: ‘<No.>’.

Previously, when Auto Suggest with AI was enabled on a template, clicking the Recognize Fields action while an AI-enhanced line suggestion job was still queued or running could result in the following error:

• Sorry, we just updated this page. Reopen it, and try again.

Now, when Recognize Fields is clicked while the AI line suggestion status is Queued or In Process, a confirmation dialog appears with the following message:

• A Suggest Lines job is still queued or running for this document. Do you want to stop it and recognize the fields again?

Clicking Yes cancels or stops the current job before starting field recognition. Clicking No leaves the job running or queued without starting field recognition.

Previously, when multiple document lines were matched to the same purchase receipt line with item tracking, selecting the Item Tracking Entries action in the Purchase Receipt Lines part of the Invoice Matching page could trigger the following error:

• An error occurred and the transaction is stopped. Contact your administrator or partner for further assistance.The following AL methods are limited during write transactions because one or more tables will be locked: Form.RunModal, Codeunit.Run, Report.RunModal, XmlPort.RunModal.Form.RunModal is not allowed in write transactions. ......

Previously, registering a purchase credit memo matched to a purchase return order could result in the following error if the return order lines contained items of type Non-Inventory or Service and were created using the Get Posted Document Lines to Reverse or Copy Document action:

• Quantity must not be greater than 0 because a corrective credit memo can only reverse the original posted invoice, not add quantity. Purchase Line: Document Type='Credit Memo', Document No.='', Line No.=''.

Previously, when two or more document lines were matched to the same posted purchase receipt line with item tracking, the following error could occur:

• Matched Quantity for item <ItemNo> on Purch. Rcpt. Header <DocumentNo> Line <LineNo> differs from Matched Quantity on Item Tracking Entries.

Previously, attempting to automatically approve an invoice matched to a purchase contract in a company using a language other than English could trigger the following error:

• The date formula '-<1W>' should include a time unit.
  Time units can be: D,WD,W,M,Q, or Y.
  C, meaning current time unit based on date, can be specified as a prefix to the time unit.

Previously, posting a purchase allocation with VAT could trigger the following error if its currency matched the Additional Reporting Currency:

• The transaction cannot be completed because it will cause inconsistencies in the G/L Entry table. Check where and how the CONSISTENT function is used in the transaction to find the reason for the error.

Purchase allocations can now be posted successfully under these conditions.

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 France PA 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 required YYYYMMDD. 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.

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 if you had the required permission sets.

This was due to Business Central online only allowing 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, so it can be changed on posted sales invoices and credit memos on Business Central online. Changes are 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 out the VATEX Code field manually.

Previously, a payment applied to an invoice while the payment itself was being posted did not appear in the F10.2 and F10.4 payment declarations.

This happened when Applies-to Doc. No. or Applies-to ID was filled out on the journal line, and when the payment was applied automatically for customers set to Apply to Oldest. Payments applied afterwards on the Apply Entries page were not affected. These payments now appear in the declarations, no matter how they were applied.

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.

When the country/region in Company Information had no ISO code, the scheduled Continia Delivery Network metadata update failed every time it ran and the job queue kept retrying it. The following error occurred:

• ISO Code must have a value in Country/Region: Code=<Country/Region Code>. It cannot be zero or empty.

The metadata update now completes. The network identifier types are still updated, but none is set as the default for your company's country until you fill out the ISO Code field on the Countries/Regions page and run the metadata update again.

When the job queue entry that updates the Continia Delivery Network metadata ran as a user with only the Continia Delivery Network - Basic permission set, the job stopped on every run with the following error:

• Sorry, the current permissions prevented the action. (TableData <Table ID> <Table Name> Modify: Continia Delivery Network)

The job queue kept retrying the job, and the networks, identifier types, network profiles, and profile document types were not updated. The Continia Delivery Network - Basic permission set now gives the metadata update the access it needs, so the job completes for users with basic permissions.

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 memos in this format are recognized as such.

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 documents. Before this change, users 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)"

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

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 sending a sales credit memo using the French CII format, the generated XML incorrectly used document type code 380 (invoice) instead of 381 (credit memo) because the document type could be overwritten by default scenario flows.

To reduce scenario configuration conflicts for invoices and credit memos, the REGULARINVOICE and REGULARCREDITMEMO scenarios have been merged into REGULARDOCUMENT .

France PA participants could not receive plain Peppol BIS 3 invoices and credit memos because the four France PA network profiles for Peppol BIS Billing 3.0 and Peppol BIS Self-Billing 3.0 were not mapped to any XML structure.

These profiles are now mapped to their Peppol BIS 3 XML structures and listed under each structure’s supported network profiles, without duplicating mappings or raising errors if the profiles aren’t present.

Sometimes, the Company Name, Country Code, and VAT Registration No. columns on the Network Participations page were empty. Since recently, these details come from the company onboarding data – which was not retrieved after the upgrade.

When you open the Network Participations page, the company onboarding data is now refreshed together with the participations and the columns show the details of the company behind each participation.

Previously, the AI capabilities for account and line suggestions were added only when Document Capture was installed for the first time. Companies that upgraded from an earlier version – including from Document Capture 2026 R1 (28.0) to 2026 R2 (29.0) – did not get these capabilities, so the suggestions were not available.

The capabilities are now added when the company is upgraded. A capability that is already set up is left unchanged, and a capability added by the upgrade is not turned on until you enable it.

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.

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.

Several labels and actions related to the custom columns functionality have been updated to align with standard Business Central naming:

• In the document journal, the Custom Columns action has been added to the Page action group.
• The page for configuring custom columns has been renamed from Custom Field Card to Custom Columns.
• The Customizable Columns FastTab on the Custom Columns page has been renamed to General.
• On the Document Category page, the Customizable Columns FastTab has been renamed to Custom Columns.

Item tracking capture has been enhanced to make it easier to process documents containing multiple item tracking values. Multiple values can now be captured for each item line, allowing all relevant item tracking information to be captured directly from the document.

For more information, see Capturing item tracking information.

On the Approval Sharing - Document Capture (DC) page, the Both Users option in the Send Email To field was previously blocked and could not be selected. The option is now fully supported, allowing both the original approver and the substitute to receive notifications when the Send Status Email to Approvers function is used.

For more information, see Setting up approval sharing.

Integrating Sustainability with Document Capture has been simplified through a new guide available in Assisted Setup. Completing the guide automatically adds the required sustainability fields to all purchase document master templates.

For more information, see Setting up the Sustainability integration.

Standard Business Central order matching actions introduced in BC 28.0 are hidden when using Document Capture.

When Document Capture is active, the standard Business Central Get Order Lines and Matched Order Lines actions, along with their corresponding columns, are hidden on purchase invoice and posted purchase invoice lines to avoid duplication with Document Capture’s order matching functionality. You can continue to use the dedicated Document Capture matching experience without interference from standard Business Central features.

It is now possible to enable a new purchase order and receipt matching engine that significantly improves the performance of three-way matching for purchase invoices and credit memos. The improvements apply to both header-level and line-level matching and are particularly beneficial in environments with large numbers of open purchase orders and receipts.

To enable it, search () for and select Continia Feature Management. Then, select the Faster Purchase Invoice Matching checkbox.

A new field, Approval Date Adjustment, has been added to the Purchase Contract Card to define a lead-time period (a.k.a. offset) for contract approvals.

For more information, see Creating purchase contracts.

A Create Purchase Contract action has been added to the Purchase Contracts page, providing the same guided experience for creating purchase contracts as from the document journal.

For more information, see Creating purchase contracts.

Document Capture now uses AI to suggest a G/L account, item, item charge, resource, or fixed asset for each unrecognized document line – significantly reducing the manual work required to code purchase invoices. For every suggestion, the AI provides a confidence level and a plain-language explanation of why the value was suggested, giving you the information needed to review and confirm the AI recommendation before it is applied to the document.

For more information, see AI-powered account and line suggestions.

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, as well as their related enums, are also available to extensions. Standard Business Central sales, purchase, and service documents continue to work as before.

Previously, upgrading Document Capture to version 29.0 could fail with the following error:

• This function requires the following module to be activated: Continia Document Capture, Document Approval.

This occurred in companies where one or more approval forwarding entries existed and the Document Approval module was not activated at the time of upgrade. The upgrade now completes successfully, regardless of the activation state of Document Approval.

Previously, sending an email with more than 200 characters in the subject line could result in the following error message during document import:

• The length of the string is x, but it must be less than or equal to 200 characters. Value: <StringThatIsTooLong>.

The subject line is now automatically truncated to 200 characters, ensuring successful import.

Previously, selecting the Recognize Fields action for a PDF could in some cases result in the following error being shown:

• The XML Structure Setup does not exist, Identification fields and values: Code=".

Previously, upgrading Document Capture to version 28.0 could fail with the following error:

• This function requires the following module to be activated: Continia Document Capture, Advanced Capture.

This occurred in environments where one or more document categories had a legacy IMAP password value stored and the Advanced Capture module was not activated at the time of upgrade.

The upgrade now completes successfully, regardless of the activation state of Advanced Capture.