Pull up the last invoice that missed its due date and find where it sat. If AP had the bill on Monday and the warehouse confirmed receipt on Friday, faster invoice entry would have saved a few minutes. Getting the receipt into the system earlier would have saved four days. Start your rollout plan with that distinction, because it decides what you are implementing.
Download the editable AP roadmap checklist and use its 90-day calendar to schedule decisions. Treat the dates as targets. If the evidence for a phase is missing, move the phase back rather than the standard.
The plan at a glance
| Target window | Owner | Evidence to bring to the review |
|---|---|---|
| Days 1–15 | AP manager | Recent bills traced from receipt through payment, with the longest waits marked |
| Days 16–30 | Controller | Signed approval and matching rules for the pilot |
| Days 31–45 | ERP administrator | Sandbox bills reconciled to the input list, including failed writes and retries |
| Days 46–60 | AP manager | Proposed actions compared with the decisions AP made on the same bills |
| Days 61–75 | Controller | Limited live activity reconciled to the ERP, with a tested way back to manual processing |
| Days 76–90 | CFO | Same-cohort results and a decision to expand, extend, or stop |
Each phase ends with a document someone signs, not a status meeting. That is what lets you defend the expansion decision later.
Days 1–15: build a baseline you can defend
Take a sample that covers ordinary processing and month-end. Keep bills tied to a purchase order, non-PO bills, recurring bills, and credits in separate groups. For each bill, record:
- when AP received it, when it became ready for approval, when it was approved, and when it posted
- due date and payment date
- minutes someone actually spent handling it
- if it waited for a receipt, who had the receipt and what finally got it into the system
Agree on the metric definitions now, before anyone has a result they would like to see. Use receipt-to-approval time for elapsed time and handling minutes for staff effort. For on-time payment, divide bills paid by their due date by all bills due in the period, including the ones still unpaid. For touchless processing, divide bills processed without manual intervention by all bills eligible for that workflow, and list every excluded bill with a reason.
Worked example: why the denominator matters (illustrative)
In the baseline month, 400 bills fell due. AP paid 352 by their due dates. The other 48 were paid late or are still open. On-time payment is 352 ÷ 400 = 88 percent. Leaving out the open bills would overstate it.
Of those 400, the team marked 250 as eligible for the new workflow, and 140 went through without anyone touching them. Touchless rate: 140 ÷ 250 = 56 percent.
Now suppose the pilot quietly narrows eligibility to 180 bills by excluding the 70 hardest ones, and the same 140 go through untouched. The touchless rate becomes 140 ÷ 180 = 77.8 percent. Nothing improved. The denominator changed. This is why the excluded list goes to the controller with every result.
Days 16–30: write the rules before you see results
Write the next permitted action beside each invoice condition. Keep the authority to release a payment separate from the authority to approve the bill.
| If AP sees this | What should happen | Who resolves it |
|---|---|---|
| Bill, PO, and receipt agree within policy | Advance to the approved next step | AP owner |
| Missing or partial receipt | Keep the hold and ask for the receipt or an explanation | Receiving or project owner |
| Price or quantity mismatch | Send the disputed line and its source documents for review | Buyer and designated approver |
| Possible duplicate | Hold with a link to the possible original | AP reviewer |
| Request to change bank details | Use the independent verification procedure for vendor changes | Vendor-master owner |
| Non-PO bill | Route to the budget owner | Budget owner |
| Write timed out | Check whether the bill posted before trying again | ERP administrator |
Set matching tolerances with the controller now. If you set them after seeing pilot results, the temptation is to widen whatever made a test fail. The three-way matching guide covers separate price and quantity limits.
Pick test cases from the work AP already has to untangle. In construction, include a bill where the job or cost code is wrong and one where retainage changes the amount due; the construction AP guide has more. In manufacturing, include a partial delivery and a bill priced in cases against a PO issued in units.
Days 31–45: make the ERP show its work
Have the ERP administrator trace a bill from its invoice ID to the final ERP record. Verify the entity, permissions, coding, and approval status. Then simulate a timeout after submission. AP checks the ERP for the original bill before retrying, and the result reconciles back to the input list.
Run these against your actual configuration:
- NetSuite. The 3 Way Match Vendor Bill Approval workflow compares vendor bills with POs and item receipts, and Oracle documents a limitation for partially received item receipts (Oracle workflow documentation). Put one in the sandbox and record who handles it. NetSuite’s period-close checklist also includes preliminary locks that limit posting (Oracle’s accounting period close documentation). Try a bill dated in a restricted period using the same role the integration will use, and have the controller decide what happens to it.
- Sage Intacct. Bills created in Accounts Payable and transactions created in Purchasing follow separate approval paths (Sage bill approval documentation). Test the path your team actually uses, and include an approver who lacks access to the bill’s entity or department.
- Other ERPs. Run the same tests against their own modules. For posted-but-blocked invoices in SAP, see the invoice holds and payment blocks guide.
| Sandbox case | What the reviewer verifies |
|---|---|
| Normal recurring bill | Entity, vendor, account, amount, and original document |
| PO bill with a partial delivery | Quantity received, amount previously billed, and the reason for any hold |
| Non-PO bill split between departments | The distribution and who can approve each portion |
| Revised bill after approval | Which fields changed and whether a fresh approval is required |
| Bill dated in a locked period | Where posting stops and who decides |
| Write that times out | One saved record after the retry |
Days 46–60: run in shadow mode
Pick one entity, a small supplier group, and an invoice type AP regularly struggles with. In shadow mode, AP works each invoice as usual while the new workflow records what it would have done.
For every disagreement, log the bill ID, the proposed action, the actual decision, and the evidence AP used. Review errors by cause. A missed duplicate and a false hold need different fixes, and so do a wrong entity and a missing attachment. Mixing them into one error rate hides which one to fix first.
Days 61–75: controlled live run and cutover
Inventory the bills in flight
On the first morning of the new workflow, a supplier forwards an invoice the old team already approved. The new queue sees a fresh attachment. Before turning on posting, list open invoices in every intake channel: email, portals, and import folders. For each, record vendor, entity, invoice reference, amount, and latest approval or posting status. Include drafts and rejected imports. A report of posted bills cannot tell you what is waiting outside the ledger.
Pick a cutover rule the team can apply without judgment calls. A common one: the old queue finishes what it already received, and new bills go to the new queue. If you transfer open items instead, move their original documents and approval history with them.
| At cutover | What AP checks |
|---|---|
| Supplier resends an existing bill | Find the draft or posted bill before creating a second record |
| A batch imports with errors | Separate accepted records from rejected rows and tie both to the batch |
| An approver was assigned in the old queue | Who owns the approval now and which version they see |
| A held bill moves to the new queue | The hold reason and its effect on payment selection |
Use your system’s import results. Oracle documents a NetSuite CSV import workflow where Import Status details show failures and an error file identifies affected rows (Oracle’s CSV import error documentation). Before resubmitting anything, look for records already saved.
Write the stopping rule
When the controller authorizes live writes, agree in advance when to pause: a bill lands in the wrong entity, appears twice, or has no traceable approval. Name the person who pauses writes and the person who reconciles anything already in flight. Resume only when someone can explain the discrepancy and account for every affected bill.
Then review the first payment run. Match the approved invoice list to saved bills, unresolved items, and held bills. Have the payment reviewer confirm that a posted bill on hold is excluded. Payment release stays with the existing team throughout.
Days 76–90: make the expansion decision from the invoice list
Bring the controller a list of every bill in the pilot, including excluded and unresolved ones. Attach the baseline, the reviewed exceptions, and the ERP record or reason for each unposted bill. Compare like with like and count new work such as exception review. The AP pricing and ROI guide and the ROI calculator help separate time AP can use elsewhere from cash the company can actually save.
| What the pilot showed | Decision |
|---|---|
| The target wait shrank and AP can explain every bill’s disposition | Expand to the next queue or entity |
| The hard cases were too sparse to judge | Extend the pilot with more of them |
| Bills still sit because nobody owns a missing receipt | Assign that owner and fix the handoff before adding volume |
| The next entity uses different approval rules | Run its exceptions in the sandbox first |
| Live writes produced unexplained records | Stop, reconcile, and repeat shadow mode |
Record who made the decision, what they approved, and when they will check the same queue again.
What goes wrong in rollouts
- The baseline is collected after the pilot starts, so nobody can say what changed.
- Tolerances are widened mid-pilot to make a test pass.
- Payment release is bundled into the go-live, so a matching error becomes a cash error.
- Retries after timeouts create duplicate bills that no one notices until the vendor statement arrives.
- The approver in the sandbox is an administrator, so access problems only show up in production.
For the stage-by-stage view of what the workflow does, see the AP automation guide.
Pilot-exit checklist
- Baseline sample with metric definitions signed before day 30
- Excluded-bill list with reasons, attached to every metric
- Tolerances and hold owners approved by the controller
- Sandbox results for partial receipt, split non-PO bill, revised bill, locked period, and timeout
- Shadow-mode disagreement log, classified by cause
- Inventory of bills in flight at cutover, reconciled after the first live week
- Named person who can pause writes, and a tested return to manual processing
- First payment run reconciled, with held bills confirmed excluded
- Written expansion decision with the date of the next review