PRODUCT CAPABILITIES
What’s in scope.
01
Creditor payments
Prepare creditor payments from Business Central and use the supported export or transmission method for the deployment. The documented API workflow retains final approval in the Absa banking application.
02
Debit-order submission
Generate debit-order requests from recurring sales transactions and send them through the bank integration. Responses return to Business Central with transaction success or failure information and relevant reason codes.
03
Bank-statement import
Import Absa transaction data into the bank or payment reconciliation journal. The imported entries are then available for matching within the Business Central reconciliation process.
04
Payment-status visibility
Keep submission and response information close to the payment workflow. This gives the finance team a basis for investigating exceptions and following up on transactions that were not accepted.
Three workflows with defined approval points
Confirm the connection method before scoping payments. The current Help guide documents file import/export and limits API integration to on-premises. Braintree should verify the installed release, bank service and Business Central deployment while preserving Absa’s approval controls.
✓
Confirm the Business Central company and Absa account in scope.
✓
Assign responsibility for payment preparation, transmission and final bank approval.
✓
Agree how failed debit orders and payment exceptions are handled.
✓
Validate statement imports and reconciliation with representative transactions.
01
From supplier invoice to bank response
Absa Bank Integration brings the preparation of creditor payments into the Business Central payment journal. Finance can use suggested vendor payments or enter journal lines directly, then review the amount, bank account and supplier reference before submission. The workflow separates preparation, internal authorisation, bank transmission and final approval in the Absa banking application. That separation gives each person a defined responsibility and keeps the bank response connected to the accounting record.
The detailed Help guide requires an approval workflow before a payment batch can be submitted. A company reference prefix and unique batch numbering support transaction references. The vendor record also needs the preferred bank account and the account reference that should appear on the statement. These are implementation inputs, not information the extension can infer reliably from an invoice.
02
Handle paid, pending and rejected payments
The documented payment process distinguishes Paid, Pending and Rejected responses. A pending response requires follow-up; it does not establish that the supplier has received the funds. The integration stores bank correlation and response information against submitted payments, giving the team a reference when investigating an exception.
Only lines with Paid status are posted in the documented workflow. The Help guide also describes a job queue option that checks pending payments and posts lines when their status permits it. Whether that automation is enabled should follow the finance team’s agreed operating model. Duplicate references, invalid bank details and rejected submissions need a clear owner before the first live payment run.
03
Collections and reconciliation have different jobs
The product page describes debit-order requests generated from recurring sales activity, with success or failure responses and reason codes returned to Business Central. It also describes statement import into the bank or payment reconciliation journal. These functions should be demonstrated separately because a collection request, a bank response and a reconciled ledger entry represent different stages of the process.
Microsoft describes the payment reconciliation journal as a place to import statement information, review suggested matches and post reconciliation entries. The Absa extension supplies supported bank connectivity and formats; the finance team still reviews unmatched amounts, fees, references and timing differences within its reconciliation process.
04
Confirm the Absa connection for your environment
The detailed Absa Help page currently documents file-based statement import and payment export, and states that its API integration is available for on-premises deployments but is not currently supported for cloud. This is a material qualification to the broader product page. The exact connection method must therefore be confirmed for the installed extension version, Business Central deployment and Absa service being used.
A useful assessment starts with the Business Central company, each bank account, the required payment and collection services, and the bank-side access already enabled. Braintree can use that information to define which workflows are supported and which setup, permission and testing work belongs in the engagement.
05
Review a complete payment cycle
The implementation review should follow representative transactions from preparation through bank response and reconciliation. Include a valid supplier payment, a rejected reference or account scenario, a pending response and a statement entry that requires manual investigation. This makes the acceptance criteria specific to the finance operation.
Confirm the required Absa access and supported connection method for the actual environment.
Allocate preparation, approval, transmission, reconciliation and exception responsibilities.
Check vendor bank details, reference conventions and unique payment-batch numbering.
Agree the use of job queues and the evidence required before a payment is posted.
EVIDENCE & DOCUMENTATION
See the work in context.
Documented Absa payment controls
The Absa Help guide describes batch approval, bank correlation IDs, payment statuses and posting restricted to paid lines. It also records the on-premises API qualification.
Explore the documentation
BEFORE YOU DECIDE
