Non-PO Invoices: How AP Codes the GL Account and Routes the Approval Without a Purchase Order
A purchase order tells AP three things before the invoice arrives: what was bought, who asked for it and which account it belongs to. A non-PO invoice tells AP none of them. It lands in the inbox, someone guesses at the GL account, forwards it to whoever might own it, and waits. This post covers how to code non-PO invoices and route them to the right approver without the guesswork.
In brief
- A non-PO invoice has no purchase order to say what was bought, who asked for it or what account it belongs to, so AP has to rebuild those three facts from the invoice itself.
- Most non-PO invoices come from a small set of recurring vendors, such as utilities, rent, software subscriptions and professional services, whose coding barely changes month to month.
- A coding rule keyed on vendor, service description and ship-to or service location resolves most non-PO invoices; only the rest need a person to decide.
- Approval follows the cost center the invoice is coded to, with amount thresholds on top, so the coding decision must come before routing, not after.
Why non-PO invoices stall
Invoices with a purchase order have a clear path. The PO names the requester, the budget and the expected amount, and the invoice is matched against it and the receipt. Exceptions exist, but the question is always the same: does the invoice agree with what was ordered and received? A non-PO invoice has no such anchor. The questions are open: what is this, where does it go, and who says it is fine to pay?
In most AP teams the answer is an e-mail. The clerk forwards the invoice to a manager who might know, that manager forwards it to someone in their team, and a week later it comes back coded, approved, or neither. Meanwhile the due date passes, the vendor sends a reminder, and the same invoice may be entered a second time from the reminder. Non-PO invoices are often a minority of the count but a majority of the time AP spends chasing people.
The fix is not to force a purchase order onto every rent payment and software renewal. Most non-PO spend is recurring or contractual, and a PO per invoice adds paperwork without adding control. The fix is to make the two decisions a PO would have made, coding and approval, from the invoice itself, with rules for the predictable cases and a clear queue for the rest.
3
facts a PO supplies that a non-PO invoice does not: item, requester, account
6
spend categories in the chart below
7
steps in the routine at the end of this post
Where non-PO invoices come from
Before writing rules, look at what the non-PO invoices actually are. For most companies they fall into a handful of categories, and the large ones are dull in the best way: the same vendors, the same services, at much the same amounts, every month.
Utilities and telecom
Software subscriptions
Professional services
Rent and facilities
One-off purchases
Travel and other
Utilities, telecom, subscriptions and rent are predictable. Each vendor bills one kind of service, usually to one site or department, so the GL account and cost center rarely change. Professional services, one-off purchases and travel are not. A law firm may bill one matter to legal and the next to a business unit; a hardware store invoice can be office supplies or a capital item. These are the invoices that need a person, and they are much easier to give proper attention once the predictable ones are out of the way.
Coding rules that hold up
A coding rule assigns a GL account and cost center to an invoice from what it says. The simplest rule is a default per vendor, and for single-service vendors that is enough. It breaks as soon as one vendor bills several kinds of service or several locations, so a rule that holds up looks at three things.
The vendor
Identify the vendor by tax ID and name, not by the sender's e-mail address, and look up its history: the GL accounts and cost centers its last several invoices were coded to. If they are all the same, that is the default. If they vary, the vendor needs a finer rule or a person.
The service description
Read each line item, not just the total. A facilities vendor that bills a monthly cleaning fee and an occasional repair is two rules, because cleaning is an operating expense and some repairs are a capital question. A line whose description matches no rule should never inherit the vendor default.
The location or department
Ship-to address, service address, site name or an attention line usually decides the cost center. A telecom bill for a warehouse belongs to that warehouse, not to the head office that signed the contract.
Code by line, not by invoice
What a coded invoice looks like
In the example below a facilities vendor sends its monthly janitorial invoice for a warehouse, with no PO number. The rule for this vendor knows the janitorial service, its GL account and the warehouse cost center. This month there is a second line, an emergency floor repair, that the rule has never seen.
{ "invoice": { "vendor_name": "Example Facilities Services Inc", "vendor_tax_id": "98-7654321", "invoice_number": "FS-20931", "invoice_date": "2026-10-20", "service_period": "2026-10-01 to 2026-10-31", "service_location": "Warehouse 3, 220 Harbor Rd, Tacoma, WA", "attention_to": "Operations", "line_items": [ { "description": "Monthly janitorial service", "amount": 2400.00 }, { "description": "Emergency floor repair", "amount": 3150.00 } ], "invoice_total": 5550.00, "po_number": null }, "coding_rule": { "vendor_id": "V-02217", "default_gl_account": "6410 Janitorial", "default_cost_center": "CC-310 Warehouse 3", "expected_monthly_amount": 2400.00 }, "result": [ { "line": 1, "gl_account": "6410", "cost_center": "CC-310", "status": "coded by rule" }, { "line": 2, "gl_account": null, "cost_center": "CC-310", "status": "needs coding: description not in rule" } ], "route_to": "budget owner of CC-310; amount above 5000 adds the site director"}The first line codes itself. The second keeps the cost center, because the service location still says Warehouse 3, but the GL account is left open for a person: a floor repair might be maintenance expense or, if large enough, a capital improvement. The total is also more than twice the expected monthly amount, which on its own is worth a look. And because the amount crosses the threshold, routing adds a second approver.
Routing the approval
Approval should follow the coding, not the other way round. Once an invoice is coded to a cost center, the approver is whoever owns that budget, and the amount decides whether anyone else signs too. A threshold table, kept by finance and not by each manager, makes this mechanical: up to one amount, the cost-center owner; above it, their director as well; above a higher amount, finance.
The attention line or requester name printed on the invoice is a useful hint but a poor approver. The person who called the repair company is not necessarily the person accountable for the budget it is charged to. Use the name to ask questions, and the cost center to decide who approves.
Two more rules keep the queue moving. Every invoice has an owner at every moment, so nothing waits in a shared inbox with nobody responsible. And an approver who is away has a named delegate, set in advance, rather than an invoice that waits for their return. The age of each invoice in the queue, measured against its due date, is the one number worth watching.
Controls that still apply
Without a PO and a receipt, some checks matter more, not less. Non-PO invoices are where duplicate invoices slip through, because a reminder or a re-sent copy has no PO match to collide with. A changed bank account printed on a utility bill deserves the same remit-to verification as any other. A service period that spans month end needs an accrual or a prepaid schedule, and an invoice from an out-of-state vendor with no sales tax may need a use tax accrual. None of these depend on a purchase order; all of them depend on reading the invoice properly.
A non-PO invoice routine for AP
- Read vendor tax ID, invoice number, service period, service location, attention line and every line item as separate fields.
- Match the vendor by tax ID and name, and pull the GL accounts and cost centers its recent invoices were coded to.
- Apply coding rules line by line, keyed on vendor, service description and location; leave unmatched lines open.
- Send lines no rule covers, and invoices far from the expected amount, to a person to code.
- Route approval to the owner of each coded cost center, with the threshold table adding approvers by amount.
- Run duplicate, remit-to, accrual and use tax checks on every non-PO invoice before it is released for payment.
- Review new coding decisions monthly and turn repeated ones into rules.
The last step is what makes the rules improve. Every invoice a person codes is a candidate for a new rule, and a vendor coded the same way three months running rarely needs a person again.
Where extraction fits
Every rule above depends on fields that sit inside the invoice: line descriptions, service address, service period, attention line. Keyed by hand, they are the first thing skipped, and the invoice is coded from the vendor name alone. Parser extracts each invoice into structured JSON against the fields you define in a template, line items included, whether it arrives by upload, e-mail or the API. Your ERP or a short rule then applies the coding and routes the approval. The judgment calls, a repair that might be capital or a service nobody recognizes, stay with the people who own the budget.