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).
Vigtigt
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 | Refactored HandleRequestEntryResponseArray to use foreach for JSON array iteration in all bank import codeunits. Removed unused loop counters and simplified redundant blocks. No behavioral change; improves code readability and consistency. | 59064 |
| General Application | Fixed Camt 054 import blocking when Status Request Header contained In Progress entries. Improved stale entry detection with type-specific thresholds (1 hour for authentication, 3 hours for imports/status). Stale entries are now marked as Failed, preventing indefinite polling. | 71818 |
| General Application | Added action to apply partial payments in payment import. See The Payment Application Review page. | 74791 |
| General Application | Separated PSD2 and EBICS URL routing logic in BANKSapi integration. Added FileType parameter to ICommunicationTypeSpecificUrlValue interface. EBICS-specific routing now handled by dedicated codeunit. No end-user impact; internal refactoring for clarity. | 74974 |
| General Application | Improved BANKSapi Account Statement import to handle JSON array responses. Each entry in Base64-encoded JSON arrays is now decoded and imported individually, ensuring complete data capture. See Onboarding through BANKSapi. | 74975 |
| General Application | Removed unused local TryGetStatusDefinition procedure from Payment Status Management. Code cleanup with no behavioral impact. | 74976 |
| General Application | Restructured KYB step in Bank Account Setup wizard for Yapily connections. Operating Address is now primary and required; Registered Address is optional. Simplifies setup for most businesses. See Onboarding through Yapily. | 74983 |
| General Application | Added EDIFACT file type (ordinal 30) to File Type enum. Enables processing of EDIFACT-formatted files in Continia Online request headers, alongside CAMT053, MT940, PAIN001, etc. | 74985 |
| General Application | Added validation for GZip decompression during bank communication imports. Responses not in Completed state are routed to error handling, preventing decompression errors for pending/failed async status responses. | 75008 |
| General Application | Added Generate Support Case Info action to Troubleshooting page. Guides users to select a scenario, collect diagnostic data, and export as ZIP. Supports Conversion Failure and Bank Agreement Not Activated scenarios. | 75192 |
| General Application | Fixed orphaned records in Multi Bank Account Assisted Setup wizard. Database records are now created only after successful bank onboarding, ensuring clean state if setup fails or is aborted. | 75213 |
| General Application | Fixed RecordMandateUsage procedure to clear Mandate Id filter before early exit. Ensures caller receives unfiltered payment entry record set, regardless of mandate usage. | 75368 |
| General Application | Added Bank Account Communication Setup data to support case export. Includes system type, transaction type, transfer, enabled status, default, and file type. Exported as JSON for further analysis. | 75409 |
| General Application | Removed duplicate OAuth refresh token call in Bizcuit bank data import. Token is now refreshed once per import, improving reliability and reducing unnecessary API requests. | 75503 |
| General Application | Changed GZip decompression handling for Danske Bank to use EOS (End of Stream) read instead of ReadText. Ensures full content of EDIFACT-formatted files is read correctly after decompression. | 75515 |
| General Application | Fixed orphaned file export queue entries when canceling Support Case Summary dialog. Queue is now cleared on cancel, preventing stale temporary export entries. | 75550 |
| General Application | Fixed conflict detection for Account Statement transaction type in Bank Account Setup wizard. Conflicts are now only checked if the bank system supports account statements, preventing false warnings. | 75713 |
| General Application | Fixed orphaned Request ID Entry records in Yapily payment export. Records are now marked as Failed and deleted if authorization is canceled, ensuring immediate cleanup. | 75826 |
| General Application | Improved AccessPay export response handling. Raw responses that cannot be decoded as JSON arrays are now archived as Payment Error for diagnostics, and processing stops early. Ensures traceability for failed or unexpected responses. | 75885 |
| General Application | Updated AccessPay Assist Setup wizard instructions. Clarifies that AccessPay onboarding may take up to 2 days before the bank is ready in Business Central. See Onboarding through AccessPay. | 75916 |
| General Application | Fix Nordea import to use per-entry metadata for uncollected request entries. | 75018 |
| General Application | Simplified Yapily setup for HSBC and Allied Irish Bank by removing Connect Profile ID requirement. Uses generic Yapily setup codeunit; bank-specific codeunits obsoleted. | 75978 |
| General Application | Improved AccessPay transaction import handling. Now uses API-based import dictionary, allowing multiple payment register entries to map to the same bank account. Previously, only the first entry per account was captured. | 75981 |
| General Application | Reorganized Troubleshooting page actions into logical groups: Logs, Files, Support, Setup & Maintenance, and Advanced. Promoted actions grouped for better discoverability. | 75986 |
| General Application | Added Manual Payment field to Bank System Payment Method table. Conflict detection now excludes manual payment methods, preventing false-positive alerts during bank system setup. | 76013 |
| General Application | Automated reconciliation matching in AccessPay setup wizard. Configures CTS-CB Date Amount Matching and Tolerance Days for selected bank accounts, eliminating manual post-setup steps. | 76142 |
| General Application | Added bulk actions to Bank Acc. Com. Setup page: All Manual, All Direct, and Set Default Communication. Enables switching transfer types for all records at once, reducing manual effort. | 76252 |
| General Application | Added exclusivity rule for Account Statement communication records. Enabling a new record automatically disables others for the same bank account, preventing ambiguous configurations. | 76253 |
| General Application | Added OnDelete trigger to Bank System table to clean up Bank System Active Map entries when a bank system is deleted. Prevents orphaned records and incorrect visibility of setup actions. | 76254 |
| General Application | Added 23 test procedures for bulk communication setup operations. Covers EnableByTransferType, SetDefaultCommunication, exclusivity, and multi-system prompts. Improves regression safety. | 76255 |
| General Application | Improved error handling for authentication cleanup. DeleteAuthenticationEntry now returns success status, and Remove Connection action shows descriptive errors if bank system is not found. | 76256 |
| General Application | Added ARUCS file type to File Type enum. Enables selection of ARUCS format for bank integrations, supporting ARUCS-formatted files without custom workarounds. | 76270 |
| General Application | Fixed bank system code resolution for payment status import. Now sources code directly from Payment Register record, ensuring correct bank system is used for accounts with multiple configurations. | 76362 |
| 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 | 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 | 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 |
| Payment Export | Introduced functionality for Payment Information Setup. See Working with the Payment Information Setup. | 70866 |
| 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 object ID range to Banking Import application for future development. Internal change; no impact on existing functionality. | 76156 |
| 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. See The Payment Application Review page. | 57675 |
| Payment Import | Added specification for payment discount handling. See The Payment Application Review page. | 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 |
Bug fixes
| Functional Area | Description | ID |
|---|---|---|
| Payment Import | Fixed issue where refreshed authentication tokens were not committed before API calls, risking token loss if the API failed. The RefreshConnection method now returns a Boolean to ensure tokens are committed before proceeding. | 74714 |
| General Application | Resolved Yapily payment export failures caused by JSON mutation, improper error handling, and incorrect token extraction. JSON is no longer mutated before status updates, and errors now trigger proper rollback. | 75811 |
| General Application | Corrected Yapily payment export issues with incorrect JSON keys and hardcoded File Type parameter. JSON keys are now accurate, and the File Type parameter is dynamic. | 75812 |
| General Application | Fixed payment status import failures due to missing bank system tracking. The bank system code is now stored on the Payment Register and used to resolve the correct communication type during status imports. | 75813 |
| Payment Export | Updated the action caption from Payment Info. Setup to Payment Information Setup for clarity and consistency across customer, vendor, and employee ards/Lists. | 75972 |
| Payment Export | Fixed issue where the Exported to Payment File flag was not reverted on canceled interactive exports, causing entries to remain marked as exported. Rollback logic now resets the flag and payment status. | 76118 |
| Platform and Technology | Resolved demo app setup limitation where only one authentication entry was created for multiple bank systems. The setup now iterates over all active bank systems and uses the provided bank system code directly. | 76361 |