Table of Contents

Linc Bank Account Enhancements User Guide

Introduction

Welcome to the user guide for Linc Bank Account Enhancements, an extension app built for Microsoft Dynamics 365 Business Central by Linc Communications (Pty) Ltd. This guide will help you set up and use the various features of the app to enhance your banking operations.

Enhancements Included

  1. Customer Preferred Bank Accounts
  2. Vendor Bank Account Enhancements
  3. Bank Account Card Enhancements
  4. Restrictions on Payment Journals
  5. Bank Account Reconciliation Enhancements
  6. Payment Reconciliation Journal Enhancements
  7. FNB Bank Statement Integration
  8. Payment Journal Export
  9. FNB Payment API Integration

1. Customer Preferred Bank Accounts

Setup

  1. Table: CustPrefBankAccount_BANK_LINC

    • Navigate to the Customer Preferred Bank Accounts page to add or edit preferred bank accounts for customers.
    • Specify the Customer No., Currency Code, and Bank Account No..

  2. Page Extension: CustomerList_BANK_LINC

    • In the Customer List page, use the "Preferred Bank Accounts" action to manage preferred bank accounts for selected customers.

Usage

  • Reports: Preferred bank account details will automatically be included in the following reports:
    • Standard Sales Invoice
    • Sales Credit Memo
    • Sales Order Confirmation
    • Customer Statement
    • Pro-Forma Invoice
    • Sales Draft Invoice
    • Sales Quote

2. Vendor Bank Account Enhancements

Setup

  1. Page Extension: VendorBankAccList_BANK_LINC
    • Navigate to the Vendor Bank Account List page to add or edit bank branch names for vendor bank accounts.

Usage

  • Factbox: Vendor bank account information will be displayed in a factbox on the following pages:
    • Posted Purchase Invoices
    • Purchase Invoices
    • Purchase Invoice
    • Vendor Ledger Entries

3. Bank Account Card Enhancements

Setup

  1. Page Extension: BankAccountCard_BANK_LINC

    • Navigate to the Bank Account Card page to set up the following fields:
      • Direct Tfr. Batch Limit
      • Netcash Service Key

  2. Page Extension: GeneralLedgerSetup_BANK_LINC

    • In the General Ledger Setup page, enable the use of the Bank Branch List for selecting/capturing branch codes.

  3. Page Extension: BankExpImpSetup_BANK_LINC

    • In the Bank Export/Import Setup page, specify the Bank Export/Import file type: Text, CSV or API. Text and CSV produce a payment file for manual upload; API sends the batch directly to the bank (see FNB Payment API Integration). The API option requires a Premium subscription.

  4. Codeunits: Ensure the appropriate bank export format codeunit is configured for your banking institution on the Bank Export/Import Setup page (FNB, ABSA, Standard Bank, Nedbank, Capitec, Netcash, Investec). See Payment Journal Export below for the full list of formats and how each is run.

Usage

  • Bank Account Card: Use the Direct Tfr. Batch Limit and Netcash Service Key fields to manage direct transfer limits and Netcash services.
  • General Ledger Setup: Use the Bank Branch List for accurate branch code selection.
  • Bank Export/Import Setup: Specify the correct file type for bank export/import operations. For FNB, this also determines whether the payment batch is written to a file or transmitted to the bank via the Payment API.

4. Restrictions on Payment Journals

Setup

  1. Codeunit: Subscriptions_BANK_LINC
    • Ensure your app subscription is active to enable all features.
    • Configure the CheckBankEFTLimit procedure to set direct transfer limits.

Usage

  • Payment Journals: The app will enforce restrictions on payment journals based on your subscription status and direct transfer limits. Unauthorized actions will be prevented, ensuring compliance and security.

5. Bank Account Reconciliation Enhancements

Setup

  1. Event Subscriber: BankAccReconciliationLine_OnAfterValidateEvent_AccountNo

    • Ensure the Gen. Prod. Posting Group and VAT Prod. Posting Group fields are correctly set up in the Bank Acc. Reconciliation Line table.

  2. Event Subscriber: BankAccReconciliationPost_OnPostPaymentApplicationsOnBeforeValidateApplyRequirements

    • Ensure the Gen. Prod. Posting Group and VAT Prod. Posting Group fields in the Gen. Journal Line table match those in the Bank Acc. Reconciliation Line table during the posting of payment applications.

Usage

  • Bank Account Reconciliation: The app will automatically update and validate the general and VAT product posting groups during the reconciliation process, ensuring accurate and up-to-date financial records.

6. Payment Reconciliation Journals Enhancements

Setup

  1. Page Extension: PaymentReconJnl_BANK_LINC

    • Added fields Gen. Prod. Posting Group and VAT Prod. Posting Group.

  2. Page Extension: TextToAccMapping_BANK_LINC

    • Added fields Gen. Prod. Posting Group, VAT Prod. Posting Group, Shortcut Dimension 1 Code and Shortcut Dimension 1 Code.
    • Set values for fields to be transferred to journal lines during mapping process.
    • Added use of wildcard character: Replace unwanted text in Mapping Text field with star (*). Text before and after character will be used during mapping process.

  3. Event Subscriber: AppliedPaymentEntry_OnUpdateParentBankAccReconLineOnBeforeBankAccReconLineModify

    • Ensure field values for Gen. Prod. Posting Group, VAT Prod. Posting Group, Shortcut Dimension 1 Code and Shortcut Dimension 1 Code are correctly set on journal lines.

  4. Event Subscriber: BankAccReconciliationLine_OnAfterRemoveAppliedPaymentEntries

    • Ensure field values for Gen. Prod. Posting Group, VAT Prod. Posting Group, Shortcut Dimension 1 Code and Shortcut Dimension 1 Code are correctly reset on journal lines.

  5. Event Subscriber: MatchBankPayments_OnFindTextMappingsOnBeforeCalculateStringNearness

    • A text-to-account mapping can now be linked to a bank account. Select the bank account on the text-to-account mapping and enable ApplyLinkedTxtToAcc_BANK_LINC on the bank account card.

Usage

  • Payment Reconciliation Journals: The app will automatically update and validate the Gen. Prod. Posting Group, VAT Prod. Posting Group, Shortcut Dimension 1 Code and Shortcut Dimension 1 Code from values on Text-To-Account mappings. Enabling the ApplyLinkedTxtToAcc_BANK_LINC on the bank account card and selecting a bank account on the text-to-account mappings will ensure only mappings related to the bank account are considered.

7. FNB Bank Statement Integration

This feature retrieves bank statement transactions directly from the FNB API and populates Bank Account Reconciliation lines, removing the need to import a statement file manually.

Setup

  1. Table & Page: BankIntegrationSetup_BANK_LINC

    • Open the Bank Integration Setup page (searchable under Administration) and complete the FNB group:

      • FNB Client ID – the client ID used to authenticate with the FNB API.

      • FNB Client Secret – the client secret used to authenticate with the FNB API (stored masked).

      • FNB API Base URL – the base URL for the FNB API gateway. Enter it without a trailing slash; the OAuth token endpoint (/oauth2/token/v2) and the transaction-history endpoint (/transaction-history/retrieve/v2/...) are appended automatically. FNB provides three environments — use the one your credentials were issued for:

        Environment Base URL
        Integration https://api.i.fnb.co.za/apigateway
        Pre-production https://api.p.fnb.co.za/apigateway
        Production https://api.fnb.co.za/apigateway

  2. Bank Account

    • Ensure the Bank Account No. on the relevant Bank Account card matches the account number registered with FNB, as it is used in the API request.

Usage

  1. Page Extension: BankAccRecon_BANK_LINC

    • On the Bank Acc. Reconciliation page, use the Import FNB Bank Statement action in the Bank menu.
    • The Statement Date must be set before running the action.

  2. Report: ImportBankRecon_BANK_LINC

    • The import request page prompts for a Start Date and End Date. By default these are set to the first day of the statement-date month and the statement date respectively, and can be adjusted.
    • The End Date must be on or after the Start Date.

  3. Codeunit: FNBImport_BANK_LINC

    • Authenticates against the FNB OAuth2 endpoint using the configured credentials, retrieves the transaction history for the selected date range, and creates a reconciliation line per transaction (transaction date, description, end-to-end reference and statement amount).
    • Each line is tagged with ReconImportID_BANK_LINC (the FNB entry ID) so re-running the import skips transactions that were already imported. A message reports how many new lines were created.

8. Payment Journal Export

The extension exports vendor payment journal lines into bank-specific payment files. Each supported bank has its own export format codeunit, and all of them read the same vendor bank account details, differing only in the file layout and how the export is triggered.

Supported export formats

Bank / Format Codeunit How it runs Output
FNB EFTExportFNB_BANK_LINC Standard Export action (via Bank Export/Import Setup) Bank-specific file, or a direct API transmission when the file type is API — see FNB Payment API Integration
ABSA EFTExportABSA_BANK_LINC Standard Export action (via Bank Export/Import Setup) Bank-specific file
Standard Bank EFTExportSTD_BANK_LINC Standard Export action (via Bank Export/Import Setup) Bank-specific file
Nedbank EFTExportNED_BANK_LINC Standard Export action (via Bank Export/Import Setup) Bank-specific file
Capitec EFTExportCapitec_BANK_LINC Standard Export action (via Bank Export/Import Setup) Bank-specific file
Netcash EFTExportNetcash_BANK_LINC Standard Export action (via Bank Export/Import Setup) Bank-specific file
Investec EFTExportInvestec_BANK_LINC Standard Export action (via Bank Export/Import Setup) BulkPayment.<yyyyMMdd>_Investec.csv
Moneycorp EFTExportMoneycorp_BANK_LINC Export to Excel action on the Payment Journal Excel .xlsx file

Shared formatting helpers (zero/blank padding, reference building, special-character stripping) are provided by EFTExportFormats_BANK_LINC. Every format processes only lines with an Account Type of Vendor, and uses the vendor's Preferred Bank Account Code to locate the Vendor Bank Account whose details are written to the file.

Common setup

  1. Vendor Bank Account Card – capture the banking details used by every format (account number, bank branch, account type). Format-specific fields are also set here (for example, the Moneycorp Account Type for Moneycorp, or the Netcash/Standard Bank notification fields).
  2. App subscription – the bank EFT export formats only run when the app subscription is active (see Restrictions on Payment Journals).

Running the standard bank formats (FNB, ABSA, Standard Bank, Nedbank, Capitec, Netcash, Investec)

  1. On the Bank Export/Import Setup page, set the Processing Codeunit to the relevant export codeunit from the table above and link it to the bank account's payment export format (see Bank Account Card Enhancements).

  2. From the Payment Journal, run the standard Export action. The configured codeunit generates the bank-specific payment file for the batch.

    For Investec, the export is a CSV file with a header record (1,2,...), one payment record per vendor line (debit account, beneficiary name, account number, branch code, currency, amount, action date, message and payment reference), and a footer record (99,...) totalling the record count, amount and sum of beneficiary account numbers. Only lines with Account Type of Vendor are exported, and any commas embedded in free-text fields (beneficiary name, message, reference) are stripped so they cannot break the column layout.

    For FNB, every line in the batch must share the same Bal. Account No. — this is checked before the file type (Text, CSV or API) is even looked at, so it applies to all three. A line that pays from a different account stops the export, naming the document and line number of the mismatched line and the account the rest of the batch pays from.

Running the Moneycorp export

  1. Table & Page: BankIntegrationSetup_BANK_LINC – open the Bank Integration Setup page (searchable under Administration) and complete the Moneycorp group:
    • Moneycorp Client ID – identifies your organisation to Moneycorp; written to the ClientID column of every exported row.
  2. Vendor Bank Account Card – set the Moneycorp Account Type field (Standard or Express); exported in the Type column.
  3. Page Extension: PaymentJournal_BANK_LINC – on the Payment Journal page, use the Export to Excel action. It runs EFTExportMoneycorp_BANK_LINC, which builds an .xlsx file (PaymentJournalExport_<yyyyMMdd>.xlsx) with one row per vendor payment line and the columns: ClientID, BankingDetailsID (preferred bank account code), Surname, FirstName (vendor bank account name), Currency (line currency, or the LCY code when blank), Amount, Type (Moneycorp account type), Payment Date, Client Reference (payment reference) and Created By. The file is offered for download as soon as the action completes.
  4. Report: PmtJnlExcelExport_BANK_LINC (alternative) – a processing-only report that produces the same Moneycorp Excel layout for a selected journal template and batch via the SetFilters procedure, for use in scheduling or automation where the page action is not suitable.

9. FNB Payment API Integration

Instead of exporting a payment file and uploading it to FNB manually, a payment journal batch can be transmitted directly to FNB through the FNB Payment Execution API. The batch goes to the bank as a single instruction covering every payment in it, and that transmission — a "run" — is recorded in the Payment Export Log, which holds the exchange with the bank on the run and the outcome the bank reported for each individual payment on its lines. The journal batch is locked while a transmission is unresolved, so a payment cannot be sent twice or posted before the bank has paid it.

This feature requires a Premium subscription. The Moneycorp export and all file-based export formats remain available on the base subscription.

Setup

  1. Table & Page: BankIntegrationSetup_BANK_LINC

    • Open the Bank Integration Setup page (searchable under Administration) and complete the FNB group:

      • FNB Client ID – the client ID used to authenticate with the FNB API.

      • FNB Client Secret – the client secret used to authenticate with the FNB API.

      • FNB API Base URL – the base URL for the FNB API gateway. Enter it without a trailing slash; the payment-initiation endpoint (/paymentExecution/initiate/v1) and the status-report endpoint (/paymentExecution/retrieveReport/v1/...) are appended automatically. Use the environment your credentials were issued for:

        Environment Base URL
        Integration https://api.i.fnb.co.za/apigateway
        Pre-production https://api.p.fnb.co.za/apigateway
        Production https://api.fnb.co.za/apigateway

    • These are the same credentials and base URL used by FNB Bank Statement Integration — one field serves both, so it must point at a gateway that answers both the payment and the statement paths. If statement import is already configured, no new setup is needed here.

    • The FNB group is editable only with an active Premium subscription. Without one, the fields are read-only and a notification is shown when the page is opened.

  2. Page Extension: BankExpImpSetup_BANK_LINC

    • On the Bank Export/Import Setup page, open the record used as the Payment Export Format on the bank account, and set Bank Export/Import file type to API.
    • The field can only be changed when the Processing Codeunit ID is the FNB export codeunit (EFTExportFNB_Bank_LINC).
    • Selecting API without a Premium subscription is rejected with: "A Premium subscription is required to use the API export/import file type. Please contact Linc Communications (Pty) Ltd."

  3. Bank Account Card

    • Ensure the bank account's Payment Export Format points at the setup record configured above — this is what routes the batch to the API rather than to a file.

  4. Vendor Bank Account Card

    • Capture the recipient's Bank Account No. and Bank Branch No. as for any other export format. These are re-read from master data each time a batch is sent, so corrections take effect on a resend.

  5. Job Queue Entry (recommended)

    • Schedule a job to periodically refresh the status of runs that are still with the bank. Without one, statuses are only updated when a user runs the Update Status action manually. Either object works — both check every run that is still Pending or Submitted, and each run is committed as it goes, so an unreachable bank on one run does not cost the others:
      • Report PmtExportStatusUpd_BANK_LINC (Update Payment Export Status) — Object Type to Run = Report, Object ID to Run = 71113471. Its request page filters on Entry No., Journal Template Name or Journal Batch Name, so a job can be scoped to particular batches; save the filter as the job queue entry's Report Request Page Options.
      • Codeunit PaymentAPIMgt_BANK_LINC — Object Type to Run = Codeunit, Object ID to Run = 71113481. Use this where no filtering is wanted; it checks every outstanding run in the company.
    • The report errors rather than notifies when the subscription is inactive, so a job queue entry fails visibly instead of quietly reporting success.

Usage

  1. Sending a batch

    • From the Payment Journal, run the standard Export action as for any other FNB export. Because the linked setup record has the file type API, the batch is sent to FNB instead of written to a file.
    • Before anything is sent, every line's Account Type must be Vendor, Bank Account or Employee — those are the only recipients the API can resolve, so a Customer or G/L Account line (a G/L line for bank charges is the usual case) is rejected, with every offending line listed at once. The batch must also share one Bal. Account No. for the whole batch (see Payment Journal Export — this check applies to every FNB export type, not only the API). Once the batch clears both checks, individual lines are checked for missing recipient bank details, and again every problem found is reported together, one per line, so a single fix-and-retry covers the whole batch. Nothing is sent until the batch passes every check.
    • A payment export log entry (a "run") is created for the batch, with one log line per journal line, and each journal line is linked to the payment it was sent as.
    • The run is then posted to FNB as one instruction covering every payment in it, and the bank returns a single instruction ID for the run as a whole. On success the batch and all its payments move to Submitted and a message confirms it: "Payment batch sent to FNB successfully. Instruction ID: %1".
    • Because it is one call, the batch either goes to the bank or it does not — there is no partly-sent run. If the call fails or FNB refuses the batch, the run is recorded as Error with the bank's response stored against it, and the export stops with an error; nothing has reached the bank, so the batch can be corrected and exported again.

  2. Page Extension: PaymentJournal_BANK_LINC

    • The Payment Export Status field on each journal line shows the outcome the bank reported for that specific payment.
    • The Payment Export Logs action (Navigation group) opens the log entries for the current journal batch.

  3. Page: PmtExportLogs_BANK_LINC – the Payment Export Logs page (searchable under History) lists every run that was sent, showing the originating journal template and batch, the debited Bank Account No., No. of Transactions, Approved Lines, Control Sum, Requested Execution Date, Status (rolled up from the run's payments), Status Reason, Sent By, and Resubmitted From Entry No. where the run is a resend of an earlier one.

    The run is what the bank was given and what it reports on, so the Instruction ID, Message ID, Payment Information ID, Bank Status Code (the group status the bank returned), Sent Date/Time and Last Status Check are all here on the run, along with the JSON of the exchange.

    Compare Approved Lines with No. of Transactions to see whether a run was paid only in part — one instruction can still come back with some payments refused.

    Available actions:

    • Update Status – retrieves the run's status report from the bank, applies the outcome the bank gave for each transaction to the matching payment, and reports how many runs were checked and how many payments still have no report yet.
    • Resubmit – sends the failed payments of a run to the bank again as a new run with fresh identifiers. Recipient bank details are re-read from the vendor, customer or employee master data, so corrections take effect.
    • Lines – opens the individual payments in the run and the outcome the bank reported for each.
    • Download Request JSON, Download Initial Response JSON, Download Status Report JSON – download the messages exchanged with the bank for the run.

  4. Page: PmtExportLogLines_BANK_LINC – the Payment Export Log Lines page shows each payment in a run: the originating Log Entry No., Line No. and Document No., Account Type, Account No., Recipient Name, Recipient Bank Account No., Branch Code, Currency Code, Amount, Reference (the text that appears on the recipient's bank statement), Status, Bank Status Code, Status Reason and End-to-End ID — the identifier the bank quotes each transaction by in the run's status report, which is how a per-transaction outcome finds its way back to the right payment. Recipient Bank Account Code is available but hidden by default.

    Since the run is sent and reported on as a whole, this page has no actions of its own: update status and download the JSON from the Payment Export Logs page instead.

    The line-level Instruction ID, Message ID, Sent Date/Time and Last Status Check fields, and the line-level Update Status and JSON download actions, belong to a short-lived model where each payment was sent as its own instruction. They are hidden and disabled, and are kept only so that an extension that referenced them keeps compiling; use their equivalents on the run.

Payment statuses

Status Meaning
Pending The payment has been recorded in the log but the run it belongs to has not been acknowledged by the bank.
Submitted The bank accepted the run, so the payment is with it, but no final outcome has been reported yet.
Approved The bank has paid the payment.
Rejected The bank refused the payment. If nothing on the line needs to change, use Resubmit; if the line is corrected first, it moves to Amended instead.
Error The run never reached the bank, or a technical failure occurred. Same recovery as Rejected.
Amended A Rejected or Error payment whose journal line has since been changed (Amount, Account Type, Account No., Recipient Bank Account, Message to Recipient or Currency Code). It can no longer be resubmitted, because the log still holds the old details — send it again from the Payment Journal instead.

The batch status is derived from its lines: while any line is still Pending or Submitted the batch shows Submitted; once every line is settled, the batch is Approved only if all lines were paid, otherwise Rejected. Statuses are colour-coded on both log pages — green for Approved, red for Rejected and Error, and Amended is highlighted for attention.

The bank only produces a status report once the run reaches one of these final outcomes — approved, rejected, or failed validation. Until then, checking status has nothing to retrieve and the run and its payments simply stay Submitted; this can take anywhere from a few minutes to several days and is expected, not a fault. The Status Reason on a waiting run records when it was last checked and that no report was available yet.

When the report does arrive, the outcome the bank gives for each transaction is matched back to its payment by End-to-End ID. A payment the report does not mention takes the run's group status instead, and a status code the app does not recognise leaves the payment Submitted and says so in its Status Reason, rather than being guessed at in either direction.

Journal batch locking

Once any line in a payment journal batch has been sent to the bank, the batch is locked by PmtExportGuard_BANK_LINC to keep it consistent with what the bank holds:

  • Lines that were sent or paid cannot be changed or deleted. A line whose payment is Pending, Submitted or Approved is locked. Lines that were Rejected or ended in Error stay editable so they can be corrected and sent again — but changing one of the payment-relevant fields (Amount, Account Type, Account No., Recipient Bank Account, Currency Code, Message to Recipient, or the balancing account) automatically moves the payment to Amended instead (see Payment statuses above).
  • No new lines can be added to a batch while any of its payments is still with the bank. A line can be added once every payment already sent from the batch has ended Rejected or Error — the batch is then being reworked, not extended underneath a live payment. Use a different journal batch while a payment is still Submitted or Approved — a line added there would be a payment the bank knows nothing about.
  • A batch cannot be sent again while any line is still with the bank. Run Update Status first to establish whether those payments were made. Lines the bank has already paid never block a resend; they are simply skipped.
  • A batch cannot be posted until every line has been paid. Lines that were never sent, or that are not yet Approved, block posting.

These checks apply only to batches that were actually sent through the API — journals exported to a file are unaffected.

Troubleshooting

  • Posting a batch that was never exported – when a batch on an API-configured bank account is posted without having been exported, a confirmation is shown: "Bank account %1 is set up to export payments via API, but journal batch %2 %3 has not been exported. Are you sure you want to post it without exporting?" Cancel it if the payments were meant to be transmitted. This confirmation is skipped for a batch that could never have been sent via the API in the first place — one holding only Account Types other than Vendor, Bank Account or Employee (a G/L line for bank charges, for example) — since there is nothing the export could have done with it.
  • A line has an Account Type the API cannot send – "The FNB Payment API can only send Vendor, Bank Account and Employee lines. The following lines cannot be sent: - Document %1, line %2 is a %3 line." Vendor, Bank Account and Employee are the only Account Types the API can resolve a recipient for; move or remove any Customer or G/L Account line (a G/L line for bank charges is the usual case) before sending. Every offending line is listed at once, and this check runs before the batch's other pre-send checks.
  • Bal. Account No. mismatch – "The Bal. Account No. must be the same for all EFT Payment Journal Entries. Document %1, line %2 has Bal. Account No. '%3', but the batch pays from '%4'." Every line in an FNB batch — Text, CSV or API — must pay from the same bank account. Split the batch by Bal. Account No. and export each part separately.
  • A batch fails before anything is sent – "This batch cannot be sent because of the following: - Document %1, line %2: %3" Every line is checked up front, so every problem (for example a missing recipient bank account or branch) is reported together rather than one send at a time. Fix all the listed lines and export again; nothing is sent until the whole batch passes.
  • The batch was refused on sending – "FNB rejected the payment batch: %1 %2" (HTTP status and reason) or "Failed to send the request to the FNB API." The run is one call, so this means the whole batch was refused or never left Business Central — no payment in it was made. The run is marked Error with the bank's response stored on it; use Download Initial Response JSON on the Payment Export Logs page to see what FNB returned, then correct the batch and export again.
  • A run stuck at Pending with no Instruction ID – the send never completed, so the bank was never given the instruction. The run stays outstanding and Update Status cannot retrieve a report for it (there is no instruction ID to ask about). Where the failure was recorded the run will already read Error; a run left at Pending after an interrupted session should be confirmed with FNB before it is sent again, since it is not knowable from Business Central alone whether the request reached them.
  • Some payments in a run were paid and others refused – normal: one instruction can still come back with per-transaction outcomes. The status report is applied to each payment by End-to-End ID, so the run shows Rejected overall while Approved Lines tells you how many were actually paid. Use Resubmit to send just the refused ones again.
  • Resubmit is refused – only a batch the bank refused (Rejected) or one that failed to send (Error) can be sent again. Run Update Status first to establish where the batch stands. Resubmitting a batch that has already been resubmitted prompts for confirmation.
  • Nothing left to resend – lines the bank has already paid, lines still with the bank, and lines that were changed since they were sent (see Amended above) are never included in a resend. If every refused line on a batch has since been changed, Resubmit refuses outright and points to the payment journal instead. Otherwise, the number of lines to be sent, already paid, still with the bank, and changed is confirmed before the batch goes out.
  • A run stays Submitted for a long time with no explanation – this is expected. The bank only produces a status report once the run is approved, rejected, or fails validation; until then there is nothing to retrieve, and Update Status simply records the check and moves on, noting on the run's Status Reason that no report was available yet. Wait for the job queue to check again rather than treating this as a fault.
  • Missing recipient details – reported as part of the upfront batch check above: "You must specify the Bank Account No. for %1 %2." or "You must specify the Bank Branch No. for %1 %2." per affected line. Complete the recipient's bank account before sending.
  • Status retrieval fails with 401 or 403 – "FNB payment status retrieval failed: %1 %2". This is a credentials or permissions fault, not a payment state, and is deliberately raised as an error rather than treated as "no report yet" — otherwise expired credentials would leave every run outstanding while the job queue reported success. Check the FNB Client ID, FNB Client Secret and FNB API Base URL on the Bank Integration Setup page, including that the base URL matches the environment the credentials were issued for.

Conclusion

Linc Bank Account Enhancements is designed to streamline and enhance your banking operations within Microsoft Dynamics 365 Business Central. By following this guide, you can set up and use the app's features to improve efficiency, accuracy, and control over your financial transactions. Enjoy the benefits of a more powerful and user-friendly banking experience!