Pick a vendor payment off last month’s bank statement. Hand it to someone who didn’t prepare it and ask them to find the bill, the receiving evidence, the approval, and the ledger entry. If they have to message the approver to ask which version of the invoice was approved, you have found a gap. Better you find it than your auditors.
Automation changes where evidence lives. A person keying a bill leaves a trail in their inbox and their memory. A tool that reads the invoice, proposes coding, and writes to the ledger leaves a trail only if you design it to.
What the trail has to answer
For any transaction, a reviewer should be able to answer five questions from saved records alone:
- What was the source document, exactly as received?
- What did the tool or preparer propose, and what did a person change?
- Who approved it, and which version did they see?
- What posted to the ledger, and when?
- What happened to cash: which payment batch or receipt, and which bank line?
Walk one AP and one AR sample through those questions.
| Sample | Evidence to retrieve |
|---|---|
| Vendor payment | Original bill, receipt or service evidence, approval, payment batch, bank result |
| Supplier bank detail change | Independent verification and the approved change before any payment to the new account |
| Customer short payment | Invoice, remittance, applied cash, and review of the deduction |
| Customer credit memo | Original invoice, reason, approval, and where the credit was applied |
Always include one transaction that was corrected or reopened. Compare the original and changed records and check whether the change needed a new approval. Oracle documents that NetSuite system notes can show who made a change, when, and the old and new field values (Oracle’s system notes documentation). Use transaction history like this to trace the change, and keep the approval or supporting record with it. Field history tells you what changed; only the approval record tells you whether it should have.
Access: give the workflow only what the task needs
Before connecting any tool to the ledger, ask the vendor what happens if AP approves a bill that carries a new bank account. Can the tool update the vendor record? Can it release payment? Ask them to show which permissions allow or block each action.
| Action | Typical automated role | Keep with authorized people |
|---|---|---|
| Read invoices from an inbox | Yes | |
| Look up vendors, POs, receipts | Yes | |
| Create a draft bill or proposed coding | Yes | |
| Post a bill after approval | Possibly, within a defined scope | |
| Change vendor bank details | Yes, with independent verification | |
| Create a new vendor | Yes, or with review before activation | |
| Release a payment run | Yes | |
| Post manual journals to control accounts | Yes |
Check the service account in the accounting system and test that actions outside its role are actually denied. “The tool doesn’t do that” is not the same as “the tool can’t do that.”
For a multi-entity ledger, use two test entities with different access. Have an AP user open an invoice from each and confirm the source document follows the same access rules as the accounting record. A PDF stored outside the ERP with looser permissions undoes the entity restriction. Also check who can export data and who can revoke the connection. The duplicate payments and vendor master guide covers bank-change verification in more detail.
Data handling and vendor assurance
Get data terms in writing before sending real invoices. Ask:
- Which providers process invoice text?
- How long are source documents and logs kept?
- Can any of those records be used for model training?
- Who at the vendor can access records for support?
- What happens to copies after you delete a bill or end the contract?
Use redacted documents until the team has approved the data flow.
If the vendor provides a SOC 2 report, read it rather than filing it. Check which service and which period it covers, and confirm the described system includes the product and connection you plan to use. Read the exceptions. Then find the controls the report expects your company to operate (often called complementary user entity controls); if you don’t operate them, the report’s conclusions may not hold for you. The AICPA publishes the criteria for describing a system in a SOC 2 report (AICPA SOC 2 description criteria).
Integration controls: prove each bill posted once
The integration sends a supplier bill to the ERP and gets no response. AP sees a timeout. The ERP may already have saved the bill. If the integration retries blindly, you now have two open bills for one invoice, and the second will pay unless someone catches it.
Three design rules prevent the duplicate:
- Name the system of record for each field. The ERP owns posted amounts and statuses. Decide where the source invoice and approval live.
- Carry a stable reference. Every approved draft gets an ID that travels into the ERP record, so AP can trace a saved bill without relying on a filename.
- Check the destination before retrying. Search for the reference first; only resend if nothing is found.
NetSuite, for example, documents create-or-update operations that identify a supported record by type and external ID (Oracle’s NetSuite upsert documentation). Confirm which records support it. If an existing bill is found, check its status and approved contents before deciding an update is authorized.
Run these cases in a sandbox using the role that will operate the integration:
| Test | What AP should be able to show |
|---|---|
| Bill posts successfully | Source reference, ERP record ID, amounts and coding that posted |
| ERP rejects the bill | The reason (invalid coding, closed period) and who owns the fix |
| Connection times out | Whether the ERP saved a record and what still needs confirming |
| Part of a file imports | Which rows posted, which failed, which can be resubmitted |
| Bill is on payment hold | Hold status saved, and payment selection excludes it |
For file imports, reconcile accepted and rejected rows against the submitted batch. For API connections, check the destination record, not only the response. The invoice holds guide covers making sure holds survive posting.
Illustrative example: a partial import
AP submits a batch of 40 bills totaling $186,400. The ERP accepts 37 bills totaling $171,250 and rejects 3 totaling $15,150 for a closed-period date. Check: $171,250 + $15,150 = $186,400. The reviewer should see all 40 references, the 37 ERP record IDs, and the 3 rejection reasons, and the 3 rejected bills should be back in a queue with an owner. If the batch total reconciles but the counts don’t, stop before resubmitting anything.
Reports a reviewer can reproduce
The CFO asks why plant maintenance spend rose. One report includes bills posted this month. Another includes invoices for work performed this month, even if they posted later. Both answer real questions. Label which date each uses.
Define the number before building the view: the account range, locations, entities, posting period, and treatment of credits. NetSuite’s Transaction Detail report includes transaction date, document number, and account (Oracle’s Transaction Detail Report documentation). Fields like these let you trace a total back to source; confirm the period and filters match the total you’re explaining.
| Save with the report | Why |
|---|---|
| Period, currency, and entity filters | Shows which transactions are in scope |
| Account and dimension definitions | Shows why a bill counts as maintenance or belongs to a plant |
| Refresh time and source | Separates a current balance from an earlier snapshot |
| Underlying transaction IDs | Lets the reviewer verify which bills or credits drove the change |
| Reconciliation to the ledger | Shows how much is explained and what remains open |
If a tool answers questions in plain language, ask it the same question (“What did we spend on maintenance last month?”) from two roles with different entity access. Each answer should match the approved report for that role and show its scope. If “last month” could mean calendar month or posting period, the tool should ask or state its assumption.
Reconstruct one bill end to end
After any pilot, give someone outside it an invoice ID and ask them to produce: the original document, proposed coding, reviewer changes, approval, and final ledger entry. Then give them an invoice whose write timed out. The record should show what happened, who checked the ledger, and whether a retry was needed. Include one bill on payment hold and confirm the hold stayed in effect after posting.
Finally, agree on incident ownership. If a connection writes an incorrect record or exposes a document to the wrong team, someone needs the authority to stop the workflow, the means to identify affected records, and a plan to correct them. Write down who that is before go-live; the implementation guide has a rollout plan that includes it.
What goes wrong
| Symptom | Likely cause |
|---|---|
| Approver can’t say which invoice version they approved | Approval not tied to a saved version |
| Two open bills for one invoice | Retry after timeout without checking the ERP |
| Vendor bank change paid before verification | Service account or AP role can edit bank details |
| SOC 2 report on file but user controls not operated | Report read for the opinion only |
| Two reports show different spend for “last month” | Posting date vs. service date not labeled |
Quarterly audit-trail sample
- Trace two vendor payments from bank line back to source document
- Trace one customer short payment and one credit memo to approval
- Include one corrected transaction and confirm re-approval where required
- Attempt a vendor bank change and a payment release with the integration’s role; both should be denied
- Reproduce one management report from saved filters and transaction IDs
- Reconstruct one timed-out or rejected write from the logs
- Log every gap with an owner and verify it on the next sample
For close-period evidence, see the month-end close checklist.