Detailed changelog for Continia Banking 2026 R1
This article lists all new updates, features, service packs, and hotfixes for Continia Banking 2026 R1.
Tip
As a Continia partner, we can notify you of new Continia Banking versions and service packs whenever we release them. To sign up for this service, go to this page in the Continia PartnerZone (only available to partners).
Important
Continia Banking 2026 R1 supports the following version of Microsoft Dynamics 365 Business Central: Business Central 2026 R1 (v28).
Continia Banking 2026 R1
Pre-release date online: March 20, 2026
Release date online: April 1, 2026
Release date, on-premises: pending
Continia Banking version: 28.0.0
New functionality
| Functional Area | Description | ID |
|---|---|---|
| General Application | Introduced an enumeration that defines Account, BulkPayment, and SinglePayment token types for Yapily authorization. This improves token management and ensures the correct Yapily API endpoints are used during payment batch authorization. | 73934 |
| General Application | Updated dependency versions and runtime. | 57076 |
| General Application | Introduced an interface that supports bank‑specific rules for grouping payments into batches prior to export. The interface standardizes batch creation and user‑interaction requirements across different bank strategy implementations. | 73936 |
| General Application | Defined an interface for communication types that require user interaction (SCA) during the export flow. Supports two‑phase Yapily‑style authorization by separating PreparePayment and SubmitPayment logic. | 73938 |
| General Application | Introduced a table for storing authorization data returned from PreparePayment, such as token type, expiry, and batch state. The table is read during SubmitPayment to continue the Yapily authorization process. | 73935 |
| General Application | Implements the Yapily SubmitPayment method that validates token freshness, retrieves the stored payload, exchanges the consent for an access token, and submits the payment. Updates journal line status based on the Yapily response and marks the batch as submitted. | 73942 |
| General Application | Updates the export orchestrator to detect whether a communication provider supports interactive export and route the flow accordingly. Interactive providers use the PreparePayment path, while non‑interactive providers continue with the standard SendPayment flow. | 73945 |
| General Application | Extends the BankExportFactory to return the correct batch‑strategy implementation based on the communication type configuration. Resolves the Yapily strategy when applicable, and falls back to the default strategy otherwise. | 73943 |
| General Application | Creates a page that lists payment batches pending authorization, allowing users to authorize or cancel each batch. Displays batch details, expiry status, and refreshes automatically while tracking prepared batches. | 73944 |
| General Application | Implements callback handling that processes Yapily authorization responses, retrieves the matching batch, and triggers SubmitPayment. Validates token expiry, submits the payment, updates the batch status, and reports success or failure. | 73946 |
| General Application | Implements the Yapily PreparePayment method that converts journal lines to Yapily format, calls the PreparePayment API, and stores authorization data for the SCA flow. Returns the authorization URL and records token details with a five‑minute expiry. | 73941 |
| General Application | Creates a scheduled job that removes expired Payment Batch Auth records still in Prepared status and resets their linked journal lines. Helps clean up abandoned authorization sessions caused by browser closures or crashes. | 73948 |
| General Application | Adds integration tests for the complete Yapily Prepare‑Authorize‑Submit flow using test doubles for the Yapily API. Verifies journal status transitions, abandoned‑flow cleanup, expired‑token handling, and correct orchestration of interactive and non‑interactive exports. | 73951 |
| General Application | Introduces a test suite that simulates Yapily responses to validate PreparePayment, SubmitPayment, token expiry checks, and batching rules. Ensures correct status updates, error handling, and integration behavior as part of the CI pipeline. | 73950 |
| General Application | Implements cleanup logic on page close to reset journal line statuses and remove any Prepared Payment Batch Auth records left unsubmitted. Ensures abandoned authorization batches are cleared and the system returns to a consistent state. | 73947 |
| General Application | Adds support in the file conversion service to transform in‑house JSON into Yapily’s payment format for export flows. Includes a new Yapily file type and system‑type mapping used before PreparePayment sends data to the Yapily API. | 73952 |
| General Application | Adds unit tests to validate enums, interfaces, and default implementations introduced in the Yapily foundation layer. Ensures field behavior, strategy defaults, and interface contracts compile and function as expected. | 73949 |
| General Application | Implemented Yapily‑specific batching rules that group payments by currency, limit bulk batches to five payments, and isolate amounts above a configured threshold. This strategy is selected for Yapily communication types and requires user interaction. | 73939 |
| General Application | Provided a default batch‑strategy implementation that returns all input lines as a single batch for banks without special requirements. Used when no bank‑specific strategy is configured and no user interaction is required. | 73937 |
| General Application | Adds localization support to the release pipeline. | 75310 |
| Payment Export | You can now see which vendor entries have been exported to the payment journal. | 67855 |
| Payment Export | Minor usability improvements in entry application. | 70610 |
| Payment Export | Added Payment Information Setup fields for customer, vendor, and employee. | 70864 |
| Payment Export | Added a new page for Payment Information Setup. | 70865 |
| Payment Export | Added all Sales Invoice and Purchase Invoice page extensions to sales credit memo and purchase credit memo. | 71947 |
| Payment Export | Added default Sender Reference Templates and summarized payment templates in Banking Export Setup (Banking DE). | 73512 |
| Payment Export | You can now move all payments from multiple payment suggestions to a new bank account in payment distribution. | 73273 |
| Payment Export | Extends the OnBeforeGetCustomerInformationAsCreditor publisher to include journal template name, journal batch name, and journal line number. This allows consumers to retrieve required general journal line data when populating CTS‑CB External Payment Entry. | 75508 |
| Payment Export | The alternative information fields already available on vendor and customer cards are now also available in Company Information. | 74911 |
| Payment Export | Introduced functionality for Payment Information Setup. | 70866 |
| Payment Export (Yapily) | The payment export flow for Yapily‑connected banks now supports a two‑phase authorization process. Payments are prepared first, then submitted after the user completes Strong Customer Authentication (SCA). Token handling and batch authorization tracking have been improved. | 73933 |
| Payment Export (Yapily) | Improved error logging for the Yapily Prepare and Export flow. Errors are now clearly displayed, and a missing interface implementation was added to the communication type enum. | 75435 |
| Payment Import | Added integration event OnAfterMatchingBankAccReconciliation to codeunit 71554177 (CTS‑PI Match Reconciliation). | 75050 |
| Payment Import | Improved handling of expired payment discounts in payment import. | 67765 |
| Payment Import | Enhancements to discount handling when using payment discounts and discount tolerance. | 57675 |
| Payment Import | Added specification for payment discount handling. | 72371 |
| Payment Import | Validation now warns you when the No. field on the Bank Account Card contains restricted characters that may affect banking functions in the Payment Reconciliation Journal. | 74312 |
| Payment Import | Added integration event OnAfterProcessDDReturnEntry to codeunit 71554339 (CTS‑PI Process DD Return). | 75036 |
| Payment Import | Added external access to Posted Direct Debit Return Entry and Return Reason Code tables. | 75765 |
Bug fixes
| Functional Area | Description | ID |
|---|---|---|
| General Application | Updated permissions and added new permission checks. | 73601 |
| General Application | The SEB Bank Assisted Setup wizard now accepts Registration No. values of any length, as long as they contain only numeric characters. Previously, it required exactly 10 characters. | 75019 |
| Payment Export | Fixed an issue where manually created payment lines did not retrieve the updated Balancing Account as expected. | 74437 |
| Payment Export | Fixed potential error message when manually creating payment journal lines. Error message is: Bank Account " does not exist Specific for the Danish localization. Card Type - Payment Method Code (e.g. Pmt. Method Code 71). | 74625 |
| Payment Export | Fixed incorrect usage of Category Purpose (CtgyPurp) in SEPA/BTI payment files, where it was being applied at both PaymentInformation and Transaction levels, violating format rules. | 72055 |
| Payment Export | Fixed an issue where templates lost their field mappings after updating from version 27.4 to 27.5, causing placeholders (such as %1) to appear without their associated fields. | 75048 |
| Payment Export | Resolved a problem that caused incorrect summarization when processing entries with multiple external codes. | 75147 |
| Payment Export | Resolved a problem that caused the Continia Banking (DK) update from 27.5.0.357745 to 27.5.1.362786 to fail. | 75202 |
| Payment Export | Resolved a problem that prevented users from creating manual cash receipt journal lines with payment method Manual when no Customer Bank Account was defined, | 75206 |
| Payment Export | Resolved a problem where vendor and customer bank accounts were not updated after switching the Pay‑to Vendor or Bill‑to Customer, leading to the validation error: Pay‑to Vendor Bank Account No. does not exist. | 75357 |
| Payment Export | Aligned lookup of Payment Reference Templates with the other templates like Sender Reference Template to enable editing of templates during the lookup. It is now possible to edit existing templates and add new ones from the lookup page. | 75358 |
| Payment Export | Fixed a bug in the export upgrade where creditor bank accounts could be duplicated due to incorrect record ID-based deduplication. | 75511 |
| Payment Export | Scanning for unverified bank accounts is now significantly faster, especially in environments with many vendors, customers, or employees. | 75520 |
| Payment Export | Fixed an issue where vendor, customer, or employee bank accounts could be created without a value in the Code field. Added validation to ensure that bank account details cannot be entered unless the Code field is populated. | 75568 |
| Payment Export | Fixed an issue where the wrong validation rule was triggered for direct debit during sales invoice validation. The bank system lookup now uses the payment entry’s Initial Transaction Type, ensuring the correct validation rules are applied. | 75717 |
| Payment Import | Fixed an error causing the Import with Job Queue field to generate the following error on the Reconciliation Import Setup Page: Could not update the page | 75039 |
| Payment Import | Fixed an issue with invoking actions for importing payments on the Payment Reconciliation Journal pages, which previously showed the error: The Bank Acc. Reconciliation does not exist on empty pages. | 75021 |
| Payment Import | Fixed an issue where the WorkDate was incorrectly used for filtering bank transactions when importing bank account statements if the statement date was blank. | 73775 |
| Payment Import | Fixed an error in the import of bank statements that caused transactions not to be imported, displaying Nothing to import despite transactions being available. Added a fallback to use the To Date if the transaction date is missing. | 74718 |
| Payment Import | Resolved confusion caused by empty bank transactions in the Bank Account Reconciliation. Added a check to mark bank transactions as imported if they contain no lines for import. | 73970 |