B2B finance SaaSLicence for some flows

AP and AR automation platform testing

FintechAssuranceLabs tests AP and AR automation platforms, the category of products like Bill.com, Tipalti, Melio, and HighRadius. Test scope covers payment runs, approval chains, Nacha and ISO 20022 bank files, supplier bank detail changes, cash application, and cash forecasting. FintechAssuranceLabs engineers test AP/AR payment flows and hand over evidence that a partner bank, ODFI, or regulator can review.

What breaks in payables and receivables money flows

An AP/AR platform earns a subscription for invoice and approval workflows and a take rate on each ACH, wire, cross-border, or virtual card payment. Each defect below risks the full payment amount for one fee.

Supplier paid before the buyer's debit settles (US). The platform credits the supplier on the day it pulls the buyer's ACH debit. When the debit returns as R01 (insufficient funds) or R29 (corporate customer advises not authorized), the platform covers the amount from its own balance. R29 counts toward the 0.5% unauthorised return rate threshold in Nacha Rules Subsection 2.17.2, above which the ODFI must take additional action. See Nacha Operating Rules testing.
Payment run resubmitted after a bank timeout (US). The upload times out after the bank accepted the file, and the retry builds a new file with new trace numbers, paying every supplier twice. Nacha's reversal rules (checked on 2026-09-16) permit reversing a duplicate entry only when the RDFI receives the reversal within five banking days after the Settlement Date. Later duplicates have to be recovered from each supplier.
Supplier bank details changed and paid in the same run. A spoofed supplier email updates the bank account, and the next run pays it without a hold or callback. Since June 2026, Nacha fraud monitoring rules require non-consumer Originators and Third-Party Senders of any volume to run risk-based processes reasonably intended to identify entries authorised under False Pretenses. For euro credit transfers, Article 5c of Regulation (EU) No 260/2012, inserted by Regulation (EU) 2024/886, has required payer banks to verify the payee since 9 October 2025. A business can opt out for payment orders submitted as a package (5c(6)), and a bank that met Article 5c is not liable for a transfer to an unintended payee on an incorrect identifier (5c(8)).
Bill edited after approval (enterprise buyers). Changing the amount or bank details of an approved bill keeps the approval, and a creator in the approver group approves their own bill. A SOC 1 report covers service organization controls relevant to user entities' internal control over financial reporting, so the service auditor can report the bypass as a deviation that the customer's auditors then evaluate.
Due date computed past the supplier's terms (EU). The scheduler reads due dates in UTC and submits after the bank's cut-off, so invoices due on the run day arrive a business day late. National laws under Directive 2011/7/EU entitle a creditor that fulfilled its obligations and was not paid on time to interest at the reference rate plus at least eight percentage points (Articles 2(6) and 3(1)) and to at least EUR 40 in fixed compensation (Article 6(1)).

Licence flag and the evidence partner banks and regulators ask for

AP/AR automation carries a partial licence flag: flows where the platform receives a payer's funds and pays them on need a licence or a licensed partner, while flows that only instruct the business's own bank fall under narrower regimes. Sources in this section were checked on 2026-09-16.

United States

FinCEN defines money transmission services as accepting funds from one person and transmitting them to another person (31 CFR 1010.100(ff)(5), eCFR current to 2026-09-14). For the payment processor exemption, FIN-2014-R009 (27 August 2014) requires settlement through systems that admit only BSA-regulated financial institutions and an agreement at a minimum with the seller or creditor that receives the funds. A payables flow contracted only with the paying business fails that last condition. A money services business registers with FinCEN within 180 days of establishment, whether or not a state licenses it (31 CFR 1022.380).

States license money transmission under their own statutes; the CSBS model law is on the GLBA and money transmitter page. Its Section 3.01(b) exempts an agent of a payee only if, among other conditions, the payor's obligation is extinguished when the agent receives payment, so an AR flow that keeps the invoice open until payout does not qualify where a state enacted that section. An ODFI registers with Nacha each Third-Party Sender that transmits ACH entries for businesses (registration rule, effective 29 September 2017). Evidence to prepare:

a funds flow map per payment method showing where buyer funds sit and for how long;
daily reconciliation of the for-benefit-of account with outstanding supplier obligations in the ledger;
return rate reports per Originator, with R01 and R29 handling test results;
fraud monitoring test results for supplier bank detail changes.

European Union

PSD2 Article 37(1) bars payment services by anyone who is neither a payment service provider nor explicitly excluded. Taking a buyer's funds to pay suppliers is money remittance (Annex I, point 6); initiating transfers from the buyer's account at another provider is payment initiation (point 7). Article 3(j) excludes technical service providers that never possess the funds, except for payment initiation and account information services. Article 10(1) requires safeguarding: funds not paid out by the end of the next business day go to a separate account or secure, liquid, low-risk assets (point (a)), or are covered by insurance or a comparable guarantee (point (b)). Evidence to prepare:

an aging report of received buyer funds against the Article 10(1)(a) deadline;
verification of payee results per payment run, including the package opt-out state;
business continuity test results for bank connections and the payment run scheduler (Article 5(1)(h)).

Canada

The Retail Payment Activities Act (current to 2026-07-21) lists holding funds for an end user and initiating an electronic funds transfer at an end user's request as payment functions (section 2). A provider that performs them as a service not incidental to another business registers with the Bank of Canada first (section 23; see RPAA testing requirements). In the Bank's case scenarios on accounting software and invoice payment services (12 December 2023), software that neither initiates transfers nor holds funds is not a payment service provider, and the same software with invoice "Pay" buttons that store payment details and initiate transfers is one. A business that remits or transmits funds is also a money services business under PCMLTFA paragraph 5(h)(ii) and registers with FINTRAC. Evidence to prepare:

the end-of-day end-user funds ledger (RPAR 15(2)(b)) reconciled with the safeguarding account;
a payment function inventory per product feature with the incidental assessment.

AP/AR test scenarios

Payment run selection. Due dates in the entity's time zone, early payment discounts, netted credit notes, and runs split by currency and payment method.
Approval chains. Amount thresholds, delegation, a creator who is also an approver, and approvals reset when amount, supplier, or bank details change.
Bank file generation. Nacha CCD and CTX files with addenda, pain.001 with one structured remittance entry per invoice, and control totals after a payment leaves an approved run; remittance limits are on the ISO 20022 page.
Submission and bank responses. Upload timeouts, retries with the same file identifier, pain.002 rejects, and returns posted back to the bill.
Funding and returns. A buyer debit returned with R01 or R29 before and after the supplier credit is released.
Supplier bank detail changes. Portal, email import, and API changes with hold period, callback, and verification of payee match, close match, and no match.
Cash application. Payments matched from CTX addenda, camt.054, and lockbox files, with short payments, overpayments, and one payment for many invoices.
Cash forecasting. Scheduled runs, expected receipts, holidays, and cut-offs per value date, compared with camt.053 or BAI2 actuals.
Fees and take rate. Per payment fees and FX markup on the platform invoice reconciled with processed payments.

Integrations and protocols to cover

ERP and accounting APIs. Vendor, bill, payment, and credit note endpoints with multi-entity mapping; ERP and accounting integration testing delivers the sync scenario suite.
Bank file channels. SFTP host-to-host, EBICS, and Swift FileAct carrying Nacha, pain.001, pain.002, camt.053, camt.054, MT101, MT940, and BAI2 files; bank transfers and payment rails testing delivers the payment file format validation suite.
Bank and payment APIs. Payment initiation, verification of payee, instant payment status callbacks, and cross-border payout APIs with FX quotes.
Virtual card payments. Card issuing APIs and single-use card numbers sent to suppliers, which are cardholder data in PCI DSS scope; see how we handle cardholder data.
Supplier onboarding. KYB, sanctions screening, tax form collection, and bank account validation APIs.

Standards

Services

Guides

Blog posts

Sample deliverable

Sample, synthetic data

payment flow mapPayment flow map: card, ACH, and instant pay-ins and payouts

Payment flow map: card, ACH, and instant pay-ins and payouts
Step ID	From state	Event (webhook or file)	To state	Ledger effect	Test cases
PFM-CARD-01	Card pay-in created	Webhook payment.authorised for 150.00 XTS	Card pay-in authorised	No journal entry; the 150.00 XTS authorisation hold is stored as a memo record	TC-PF-001, TC-PF-002 (duplicate webhook delivery)
PFM-CARD-02	Card pay-in authorised	Webhook payment.captured for 150.00 XTS	Card pay-in captured	Dr Processor receivable 150.00 XTS / Cr Merchant payable 150.00 XTS	TC-PF-010, TC-PF-011 (capture retried with the same idempotency key)
PFM-CARD-03	Card pay-in captured	Processor settlement file line for the capture, with a 4.35 XTS fee line	Card pay-in settled	Dr Settlement bank cash 145.65 XTS and Dr Processing fee expense 4.35 XTS / Cr Processor receivable 150.00 XTS	TC-PF-020, TC-PF-021 (settlement line with no matching capture)
PFM-ACH-01	ACH debit pay-in pending	Nacha return file entry with return code R01 (Insufficient Funds)	ACH debit pay-in returned	Dr Customer available balance 200.00 XTS / Cr ACH clearing 200.00 XTS, reversing the provisional credit	TC-RL-030, TC-RL-031 (return received after the customer spent the provisional funds)
PFM-ACH-02	ACH debit pay-in settled	Nacha return file entry with return code R10 (unauthorised debit), inside the 60-day extended return window	ACH debit pay-in returned as unauthorised	Dr Customer available balance 200.00 XTS / Cr ACH clearing 200.00 XTS, with any shortfall moved to a negative balance receivable	TC-RL-032, TC-RL-033 (return that drives the customer balance below zero)
PFM-ACH-03	ACH credit payout sent	Nacha return file entry with return code R03 (No Account/Unable to Locate Account)	ACH credit payout returned	Dr ACH clearing 500.00 XTS / Cr Beneficiary payable 500.00 XTS, restoring the amount owed to the beneficiary	TC-RL-040, TC-RL-041 (payout retry blocked until bank details change)
PFM-INST-01	Instant payout submitted	ISO 20022 pacs.002 with transaction status ACSC	Instant payout completed	Dr Instant payout clearing 75.00 XTS / Cr Settlement bank cash 75.00 XTS	TC-RL-050, TC-RL-051 (pacs.002 received after the client timeout)
PFM-INST-02	Instant payout submitted	ISO 20022 pacs.002 with transaction status RJCT and reason AC04 (Closed Account Number), sent to the client as webhook payout.failed	Instant payout failed	Dr Instant payout clearing 75.00 XTS / Cr Customer available balance 75.00 XTS, reversing the payout debit	TC-RL-052, TC-RL-053 (payout.failed webhook delivered before payout.submitted)

Amounts use XTS, the ISO 4217 code reserved for testing. States, webhook names, and ledger accounts are generic, and no real account or card data appears.

Questions

What is accounts payable automation?

Accounts payable automation is software that captures supplier invoices, matches them to purchase orders and receipts, routes them through approval chains, and pays approved invoices in scheduled payment runs by ACH, wire, check, or virtual card. Accounts payable automation software also syncs each bill and each payment to the accounting system.

How does AP automation work?

AP automation works in five steps: invoice capture from email, supplier portals, or e-invoicing networks; coding and matching against purchase orders; approval under amount and cost centre rules; payment in a scheduled run through bank files, bank APIs, or a payment provider; and sync of the bill, the payment, and the fees to the general ledger.

What is a payment run?

A payment run is a scheduled batch in which accounts payable selects approved invoices due by a cut-off date, groups them by supplier, currency, and payment method, and sends the payments to the bank in one file or one API batch. A payment run records each payment against its invoice so that the ledger and the bank statement reconcile.

Scope your AP/AR platform testing

Send your payment methods, bank connections, and funds flow, and we return a test scope with the evidence your partner bank or ODFI will ask for.

Scope your testing