AI can configure your finance system. Who checks the configuration?
Check AI finance configuration with transaction tests for account mappings, entity boundaries, approval rules, and later changes.
Maebh Collins FCA7 min read
Published 1 October 2026
A finance system can be configured quickly and still encode the wrong rule. The acceptance decision belongs to someone who understands what the business requires and can demonstrate that the settings produce it.
On 15 September, Payhawk announced an Implementation Agent. Its product page describes mapping existing policies and account structures into Payhawk and building workflows. This concerns configuration of Payhawk. It is not evidence that an entire ERP transformation can be completed on the same timetable.
I have implemented NetSuite and Sage in international businesses. The lasting question is whether the operational requirement survives translation into system behaviour. An agent can perform that translation, but finance still needs a method to accept it. These checks connect AI in finance strategy with the wider finance transformation work.
Define the requirement before checking the setting
Start with an approved source document. It might be the chart of accounts, the entity list, a spend policy, or an approval matrix. Give it a version and identify its owner.
If two source documents disagree, resolve the disagreement before asking an agent to choose between them. A system can produce a coherent configuration from contradictory instructions. That coherence does not establish which instruction the business intended to apply.
Write each material requirement as a behaviour that can be observed. An instruction such as “follow the finance approval policy” is too broad for an acceptance test. An instruction specifying the entity, transaction type, amount boundary, and required approver gives you something to demonstrate.
The broader problems of project ownership and process design are covered in my ERP implementation article. Here the focus is narrower: checking the configuration that a machine proposes against the requirement that finance approved.
Build an acceptance table around transactions
The following table is an illustrative test plan. Its settings and thresholds are fictional. It does not describe Payhawk defects or claim that every product supports these controls in the same way.
| Requirement | Test case | Expected result | Acceptance evidence |
|---|---|---|---|
| Irish entity costs use its approved accounts | Irish entity expense with a UK account reference | Unsupported mapping is blocked or routed for correction under the agreed design | Transaction result and mapping record |
| Spend above €5,000 needs the named senior approver | €5,001 expense | Additional approval is required | Approval event and identity |
| A person cannot approve their own claim | Approver submits an expense | Claim routes to the designated alternative | Workflow history |
| Supplier bank changes require separate verification | Change followed by a payment proposal | Payment follows the verification gate | Verification and payment records |
| Configuration changes require authorisation | User without that permission attempts a rule edit | Edit is prevented | Access result and relevant log |
For each row, add the source requirement, proposed configuration, test owner, result, and outstanding issue. Keep the evidence retrievable. A tick in a spreadsheet is useful only when the reviewer can establish what was tested.
Use a suitable test environment and fictional or appropriately controlled data. Do not create real payments to prove an approval route when a safe test can demonstrate it. Finance should agree the test method with the system owner before execution.
Check mappings from both directions
A successful import proves that the system accepted a structure. It does not prove that the mapping reflects the intended accounting destination. Review material mappings with someone who understands the source and destination systems.
Start with a source transaction and follow its entity, account, department, currency, and other required fields into the destination. Then start with the destination record and trace it back. The return journey exposes fields that disappear or become difficult to interpret.
Include an account with a similar name to another account and an inactive code that should not be selected. Include a transaction missing a mandatory field. Record whether the tool stops, requests clarification, or applies a default.
Defaults deserve explicit review. A fallback account can keep an integration running while hiding a classification problem. Ask which defaults exist, who approved them, and how the finance team identifies their use in subsequent reporting.
Test the approval boundary, not just the ordinary case
If the fictional rule requires additional approval above €5,000, test €4,999, €5,000, and €5,001. The exact boundary matters. A written policy and a system condition can disagree over whether the limit is inclusive.
Then vary the entity and user. A transaction that routes correctly for one employee may take a different path for a senior approver or someone working across entities. Test the cases your business actually needs, rather than every theoretical combination.
Include the absence of the normal approver. Establish whether the process waits, routes to an approved substitute, or permits an override. Keep the authority for that behaviour attached to the requirement.
Ask the implementation owner to show the completed workflow record. A notification in an approver’s inbox is not proof that the required approval was enforced. You need to see the decision and the resulting state of the transaction.
Separate a permissions test from a prompt test
Instructions in a conversation can describe the policy you want. They should not be the sole basis for enforcing who may change a configuration or approve a transaction. Test the underlying permissions with the relevant user identities.
Use one identity that has the authority and one that does not. Attempt the same relevant action through the supported routes. If a conversational interface exists, include it in the test alongside the ordinary interface.
Record whether the action was prevented, permitted, or held for approval. Ask where the result is logged and which identity is attributed to it. Finance needs to know whether the visible record identifies the user, the service account, or both.
This links to the existing AI governance framework. The configuration test turns an access policy into observed behaviour. It gives the accountable person evidence for the acceptance decision.
Measure the cost of correction before acceptance
A fast configuration can move work into review. Record the time spent checking proposed settings, resolving source conflicts, correcting mappings, and retesting. Otherwise, an implementation-speed claim tells you little about the complete process.
Classify each correction. Was the approved requirement unclear, the source document out of date, the mapping wrong, or the test expectation mistaken? Different causes require different fixes.
If most corrections arise from old policies, improve the source documents before running the next configuration. If the same mapping repeatedly fails, change the method or proposed setting and rerun the relevant tests. A better prompt is only one possible remedy.
The acceptance record should identify unresolved issues explicitly. State who owns them and whether they prevent the affected workflow from going live. Avoid a general “accepted with comments” label that conceals which transactions remain unsafe or incomplete.
Keep the accepted configuration identifiable
When finance signs off, retain the configuration version, test results, source requirements, and approval. The record should establish which settings passed. A later change should not inherit that approval automatically.
Define which changes require retesting. A new account mapping may need a focused transaction test. A changed approval hierarchy may affect several routes and user roles. The required checks should follow the behaviour being changed.
If an agent can recommend later improvements, establish the boundary between a recommendation and an applied change. Review who can authorise the change and how the previous settings can be recovered. Do not assume that an accepted initial configuration settles ongoing change control.
The deployment stages are already set out in the pilot-to-production playbook. Configuration acceptance supplies evidence for that process. It should be complete enough that another finance leader can understand the decision without attending the original demonstration.
Before your next implementation, choose a small set of material rules and write the transactions that would prove them. That is a practical starting point whether configuration is performed by a person or an agent. If you need finance leadership to connect requirements, controls, and implementation evidence, get in touch.
Maebh Collins is a Fellow Chartered Accountant (FCA, ICAEW) with Big 4 training and twenty years of operational experience as a founder and senior finance leader.