Overview: the process is the product
Accounts payable goes wrong for reasons that software does not fix. Invoices arrive by five routes and one gets lost. Nobody knows who approves what. The same invoice is paid twice. A supplier claims a balance nobody can verify. Each of those is a process gap, and a platform installed over a gap simply automates it.
So this guide is about the process, with one technology assumption: that invoices become structured data automatically rather than being typed. That single change is what makes a manual process viable at real volume, because keying is the part that does not scale and produces no judgement.
Everything else here is discipline, and it is achievable by one careful person with a spreadsheet. If you later buy a platform, you will implement it into a process that already works — which is the only implementation that ever goes well.
Four principles the whole process rests on
One way in. Every supplier invoice arrives by one route. Not mostly. Every.
Data, not documents. An invoice becomes a row in a register on the day it arrives. Anything still sitting only as a PDF is invisible to every subsequent step.
Exceptions, not everything. Human attention goes to what is new, unusual or above a threshold. Applying the same scrutiny to the monthly hosting bill as to a first-time supplier is how a process becomes unsustainable.
Controls before the money leaves.Duplicate checks and bank-detail verification happen before the payment run, because recovery afterwards depends entirely on somebody else's goodwill.
Step 1 — One intake route, enforced
Create one address that suppliers send invoices to — a shared mailbox, not a person. Then do the unglamorous part: tell every supplier, update the address on your purchase orders and remittances, and forward anything that arrives elsewhere into it rather than processing it where it landed.
The enforcement matters more than the setup. An intake route that is used for most invoices is barely better than none, because you still cannot answer the only question that counts: have we received everything?
Paper and photographs need a route too — scanned into the same mailbox rather than into somebody's desk drawer. Quality matters here, because a dim photograph limits everything downstream; [scanned document handling](/scanned-bank-statement-to-excel) covers what survives OCR and what does not.
Step 2 — The invoice register is the system
Without a platform, the register is your AP system. One table, one row per invoice, with the fields every later step needs: supplier, invoice number, invoice date, due date, net, tax, total, currency, PO reference, status and the file it came from.
Build it by extraction rather than by typing. [Invoice extraction](/invoice-pdf-to-excel) reads all of those fields — plus line itemswhere you need them — from any supplier's layout with no template to configure, so a new supplier is not a setup task. [An invoice register](/tools/pdf-invoice-register) is the same idea assembled for a batch.
Two rules keep it usable: never delete a row, only change its status; and always keep the source-file reference, because every question anyone asks later starts with "which document is this from".
Step 3 — Coding by rule, review by exception
Most invoices come from suppliers you have paid before, and their coding almost never changes. Build a supplier-to-account mapping once — supplier, account, cost centre, tax treatment — and apply it automatically to everything that matches.
What that leaves is a short list: new suppliers, and anything whose nature varies. Those get a human decision, and the decision extends the mapping so it does not recur. After two or three months the exception list is genuinely small.
Never automate three categories: anything that might be capital rather than revenue, anything with a personal-use element, and anything where the tax treatment is unusual. Those are judgements with consequences, and a rule that gets them wrong repeats the error every month. Our [categorisation guide](/guides/how-to-categorize-bank-transactions) covers the mechanics of rules that hold up.
Step 4 — Approval by exception
Approving every invoice individually is what makes manual AP collapse. Approve by policy instead: recurring invoices from known suppliers within a normal range are pre-approved by the arrangement that created them.
What needs a fresh approval is short and specific: a new supplier, an amount above a threshold, an amount materially different from that supplier's usual, and anything with no purchase order where one was expected.
| Invoice | Approval needed? | Why |
|---|---|---|
| Known supplier, normal amount | No — policy covers it | The arrangement was already approved |
| Known supplier, unusual amount | Yes | Price change or error |
| New supplier | Yes, always | Also a fraud control |
| Above the value threshold | Yes | Materiality |
| No PO where one was required | Yes, by the requester | Buying-discipline exception |
| Credit note | Record, do not approve | It reduces what you owe |
Record approvals in the register: a name and a date in a column. It is a weaker audit trail than a platform provides and it is enormously better than an approval that lived in an email nobody kept.
Step 5 — Match what you can, honestly
If purchase orders exist, match against them: right supplier, right price, right quantity, and — for goods — actually received. If they do not exist for a category of spend, say so rather than pretending the check happened.
A weekly matching pass over the register is realistic; matching each invoice as it arrives is not, and trying is how the backlog forms. Sort exceptions by type rather than by supplier, because each type has one question and one owner — three-way matching covers the types in detail.
For spend with no PO, the substitute control is the approver: someone who knows what was ordered confirms the invoice. That is weaker than a match and it is not nothing, provided the person is the one who ordered rather than whoever is nearest.
Step 6 — The payment run
Run payments on a schedule — weekly for most businesses — rather than whenever someone asks. A predictable run reduces supplier chasing dramatically and makes the duplicate check possible, because there is a defined batch to check.
Build the batch from the register: approved, matched or approved-in-lieu, due within the horizon, not disputed, not already paid. Then run the checks below before releasing anything.
Afterwards, mark the register — status, payment date and reference — the same day. A register whose statuses lag the bank is the root cause of most double payments in manual processes.
Step 7 — After the run
Send remittance advice to suppliers listing what each payment covers. It costs minutes, it prevents a large share of "we have not received your payment" queries, and it makes their allocation correct, which makes your next statement reconciliation cleaner.
Then reconcile the run against the bank: every payment in the batch should appear, once, for the right amount. Converting the statement makes that a comparison rather than a read — see [statement conversion](/bank-statement-converter) — and it is where a failed or duplicated payment is caught within days rather than at month end.
File the remittances you receive from customers too. [Remittance advice extraction](/remittance-advice-to-excel) turns them into allocation data, which is the AR side of the same discipline.
The four controls that matter
| Control | When | What it prevents |
|---|---|---|
| Bank-detail verification | On any change request | Payment diverted to a fraudster |
| Segregation of approval and payment | Always | Unapproved or self-approved payments |
| Duplicate check | Before every run | Paying the same invoice twice |
| Supplier statement reconciliation | Monthly, largest accounts | Missing invoices and unclaimed credits |
None of these require software, all four are cheap, and between them they prevent most of what actually goes wrong in accounts payable. A team running all four with a spreadsheet is in better shape than a team running none with a platform.
The duplicate check, in practice
Two comparisons before each run. Within the batch: the same supplier and amount appearing twice. Against history: each amount checked against the last ninety days of payments to that supplier.
Duplicates rarely look identical — the common case is a supplier re-sending an invoice with a new number while chasing — so comparing invoice numbers alone misses most of them. Amount within a window catches far more.
Flag rather than remove: recurring charges of the same amount are legitimate and blocking one silently creates a worse problem. Duplicate payment detection covers the six patterns and how to recover the ones already paid.
Supplier statements: the monthly external check
Your register is your view of your own records. A supplier statement is somebody else's view of the same account, and comparing them is the only routine way to find invoices you never received and credits you never applied.
Do it monthly for your largest accounts by transaction count, and always before agreeing a payment plan or closing a year. Extract both sides so it is a table comparison rather than an eye-strain exercise — vendor statement reconciliation covers the method and the seven difference types.
Classify every difference rather than netting them off. A single unexplained difference is what makes people abandon reconciliations; a list of nine missing invoices and six unissued credits is something a person can act on this week.
Payment fraud: the one that costs the most
The largest single losses in accounts payable are rarely duplicates or coding errors. They are payments sent to a fraudster after a convincing request to change a supplier's bank details.
The control is simple and must be absolute: verify any bank-detail change by calling a number you already hold for that supplier, never a number in the email requesting the change. Do it even when the request comes from a familiar address, because that address may be compromised.
Two supporting habits: keep bank details in one place with a record of when they last changed, and treat a first payment to a new supplier as a checkpoint rather than a routine transaction.
Onboarding a new supplier
A new supplier is the highest-risk moment in accounts payable, and in most small teams it has no process at all — someone simply pays an invoice from a name they have not seen before.
Five things are worth collecting before the first payment: the legal entity name, the tax registration number, the bank details in writing on the supplier's own letterhead or portal rather than in an email body, the payment terms, and the contact for billing queries. That takes one exchange and it prevents a category of problem that is expensive to unwind.
Then check the obvious: does this supplier already exist under a slightly different name? Duplicated vendor records are the root cause behind a large share of duplicate payments, and the moment to catch one is when it is created rather than after money has left twice.
Finally, treat the first payment as a checkpoint. Small first, verified details, and a note in the register that this is a first transaction — because impersonation attempts overwhelmingly target new or newly-changed supplier relationships.
Supplier queries: the work nobody budgets for
A surprising share of AP time goes on answering the same three questions: has our invoice been received, when will it be paid, and why was this amount short.
Each has a structural fix. "Have you received it" disappears when there is one intake route and the register can be searched by supplier and invoice number in seconds. "When will it be paid" disappears when the payment run is on a known schedule and you can say so — suppliers chase far less when the answer is a date rather than a shrug.
"Why was this short" usually means a deduction nobody explained: a credit applied, a disputed line, a discount taken. Sending remittance advice with every payment removes most of these before they are asked, and the ones that remain are answered from the register rather than from memory.
Track the volume of queries for a month. If it is high, it is almost always a symptom of one of the three fixes above being missing rather than of suppliers being difficult.
Credit notes and disputes
Credit notes are money and they get lost constantly, because they arrive outside the normal invoice flow — often as an email reply in the middle of an argument rather than as a document through the intake route.
Treat a credit note as a document in its own right: extract it into the register with a negative amount, reference the invoice it relates to, and apply it at the next payment run. Credit note extraction handles the batches that arrive after a dispute is settled.
Disputes need a status of their own rather than being left as unpaid invoices. An invoice held because of a genuine dispute is not late payment, and mixing the two makes both your ageing and your supplier relationships worse — the supplier sees an overdue account, you see an unresolved argument, and neither of you is looking at the same thing.
Pay the undisputed portion. Withholding an entire payment over one contested line is the fastest route to an account being placed on hold, and it rarely accelerates the resolution.
Month-end without a platform
Four things close AP properly. Every invoice received in the period is in the register, including ones not yet approved. Accruals exist for costs incurred with no invoice yet. Supplier statements for the largest accounts are reconciled. And the bank agrees with the payment record.
The one people skip is accruals for invoices that have not arrived — which is exactly what makes a month look better than it was and the next one worse. The statement reconciliation is what surfaces them.
Fitting this into a wider close is covered in [the month-end close checklist](/guides/month-end-close-checklist); AP is usually the second-longest pole in it after cash.
Closing the loop: what the register tells you afterwards
A register built for processing turns out to answer questions nobody set it up for, and this is where a manual AP process quietly beats a platform nobody queries.
Sort by supplier and total: your top twenty suppliers by spend, which is the list any negotiation should start from. Sort by month and category: where costs moved, and whether anyone noticed. Filter for invoices with no PO reference: the size of your buying-discipline problem, as a number rather than an opinion.
Filter for suppliers with a single invoice in twelve months and you usually find a handful of one-off purchases that should have been consolidated, plus the occasional supplier record created by mistake. Both are small savings that recur.
None of these need a reporting project. They are sorts and filters on a table that already exists because you built it to pay people — which is the argument for keeping the register properly rather than treating it as a queue that empties.
What to measure
Four numbers, all available from the register with no separate reporting: invoices processed per week, share needing manual intervention, share still unapproved after seven days, and exceptions open at month end.
The second tells you whether extraction and coding rules are working. The third tells you whether approval is the bottleneck — and it usually is, which is also the honest signal that a platform might eventually be worth it.
Measure for a month before changing anything. Almost every process improvement that cannot demonstrate its value skipped the baseline.
A worked week
A services business, about 250 supplier invoices a month, one part-time AP person, no platform.
Monday. Everything in the mailbox from last week is extracted into the register in one batch — about sixty invoices, ten minutes. Coding rules cover fifty-one. Nine go to the exception list: two new suppliers, four amounts outside the usual range, three with no PO where one was expected.
Tuesday. The exceptions go out for approval in one email each, to the person who actually ordered. The matching pass runs over everything with a PO reference; three quantity mismatches go back to the warehouse.
Thursday. The payment batch is built: approved, due within ten days, not disputed. The duplicate check flags two items — one is the monthly hosting charge, one is genuinely the same invoice re-sent with a new number and is removed. The bank details on the two new suppliers are verified by phone.
Friday. The run goes out, the register is marked, remittances are sent. Total: roughly half a day across the week, and the one duplicate caught paid for the whole month of effort.
When this stops working
Be honest about the ceiling. This process breaks when approvals involve several people with different limits, when someone external will test your audit trail, when purchase orders live in a system and matching must be automatic, or when AP spans multiple entities that need consistency.
Volume alone is rarely the trigger. A single approver with clear thresholds handles several hundred invoices a month comfortably; four approvers with delegations will break a spreadsheet at a fraction of that, because chasing becomes the job.
When you do buy, you will be implementing into a defined process with clean supplier data — which is the difference between an implementation that takes weeks and one that takes a year. [AP automation](/accounts-payable-automation) sets out what a platform genuinely adds and what it does not.
Common mistakes
The seven that hurt most
- • Multiple intake routes, so nobody can say whether everything arrived.
- • Paying from a supplier statement instead of from invoices.
- • Approving everything individually until the process collapses under itself.
- • Updating the register days after the payment run, not the same day.
- • Letting the supplier list accumulate duplicates.
- • Making urgent manual payments outside the batch with no record.
- • Accepting a bank-detail change from the email that requested it.
The last one is the only item on this page that can cost a business a life-changing amount in a single transaction. Everything else is measured in hours and percentages.
The checklist
- One intake address, communicated to every supplier and enforced internally.
- Every invoice extracted into the register on the day it arrives.
- A supplier-to-account mapping covering the recurring spend.
- Written approval policy: thresholds, new suppliers, unusual amounts.
- A weekly matching pass for everything with a purchase order.
- A scheduled payment run, built from the register, never ad hoc.
- Duplicate check within the batch and against ninety days of history.
- Bank-detail changes verified by a known phone number, always.
- Register updated with payment date and reference the same day.
- Monthly supplier statement reconciliation on the largest accounts.
Automate
- • Reading invoices into the register
- • Coding the repeating suppliers
- • Duplicate scanning before a run
- • Converting supplier and bank statements
Keep human
- • Approving new suppliers and unusual amounts
- • Verifying bank-detail changes
- • Deciding what an exception means
- • Capital versus revenue judgements