Invoice-to-pay: capture to payment and reconciliation

Interviewer: Thanks for doing this. I want to walk through your invoice-to-pay process end to end, the way you'd explain it to someone new in AP. Wherever you want to start.

AP: Sure. So invoice-to-pay is everything from a supplier invoice landing with us to the payment going out and getting reconciled. People picture it as data entry, keying invoices and cutting checks, but that's maybe the smallest part of it. The real work is in matching, exceptions, and controls. Let me start with how invoices even reach us.

Interviewer: How do they come in?

AP: Every channel you can think of. Most come as PDFs to a shared mailbox, a good chunk come through EDI from our larger suppliers, some come through a supplier portal, and yes, we still get paper from a few stragglers. They get captured into our AP system, and the tool does OCR to pull the data off the invoice. And right at intake there's a fork, because a PO-backed invoice and a non-PO invoice take very different paths.

Interviewer: Okay, the invoice is captured. What's first?

AP: First we validate it. The system extracts the header and line details, and we check the basics. Is this a real vendor, is the currency right, is the tax sensible, and critically, have we seen this invoice before. Duplicate invoices are a constant. Suppliers send a reminder, it looks like a new invoice, and if you're not careful you pay twice. So the duplicate check is an early control. If something's a duplicate or it's just wrong, it goes back to the supplier.

Interviewer: You mentioned checking the vendor. Is there more to that?

AP: There is, and it's where fraud risk lives. We confirm the vendor exists in our master, isn't on hold, and that the banking details on file match. If it's a brand-new vendor, or, and this is the big one, if someone's asking us to change a vendor's bank account, we treat that very carefully. Business email compromise usually shows up exactly there, a spoofed email saying "we've changed banks, here's our new account." So a bank-detail change triggers a callback to a known number to verify it. We never update banking off an email alone.

Interviewer: Good. So for a PO invoice, what happens next?

AP: PO matching. We match the invoice against the purchase order and the receipt of the goods or services. If the price, the quantity, and the receipt all line up, it's a clean match and it can flow straight through with very little human touch. That's the dream, the touchless invoice. The problem is a lot of them don't match cleanly.

Interviewer: And when they don't?

AP: Then it's an exception, and honestly exceptions are where most of my team's time goes. The price on the invoice doesn't match the PO. The quantity's off. The goods were never receipted in the system even though they arrived. Or there's no PO at all because someone ordered something without raising one. Every one of those has to be chased down with the buyer or the requester to resolve. And for non-PO invoices, there's no PO to match against, so somebody has to code it, assign the right GL account and cost center, and that usually means going back to whoever requested it. So a big part of the job is this back-and-forth to clear exceptions, and it's mostly manual.

Interviewer: Once an invoice is clean or resolved, how does it get approved?

AP: It routes for approval based on our delegation-of-authority matrix. So depending on the amount and the cost center, it goes to the right approver, and above certain thresholds it escalates to more senior sign-off. Alongside that we handle the tax and compliance pieces, sales and use tax or VAT treatment, anything that needs 1099 or withholding handling. Then once it's approved, it posts to the ledger as a liability, and for things we've received but haven't been invoiced for yet, we accrue.

Interviewer: Then you actually pay.

AP: Then we run payments. We pull the invoices that are due based on their terms, decide the method, ACH, check, wire, sometimes a card program, and batch them into a payment run. And this is where we try to be smart about timing. If a supplier offers an early-payment discount, we want to capture it, but we also don't want to pay early for no reason, because holding onto our cash longer helps working capital. So there's a real balance between capturing discounts and managing our days payable. The run gets reviewed and released, usually by treasury or the controller, with a positive-pay file to the bank as a fraud control, and then the bank executes, remittance goes to the suppliers, and confirmations come back.

Interviewer: And after payment?

AP: We reconcile. The AP subledger has to tie to the general ledger, we reconcile the bank, and we clear the paid items. Anything that doesn't reconcile, we investigate. And separately there's a steady stream of supplier inquiries, the "where's my payment" emails, reconciling supplier statements against what we show, resolving disputes. That never really stops, it's just part of running AP.

Interviewer: And reporting on top of it all?

AP: Right. We report on AP aging, our days payable outstanding, on-time payment rate, how much discount we captured, our exception rates. And there's a whole controls layer because we're audited, the key one being segregation of duties. The person who sets up a vendor can't also approve invoices and release payments, because if one person could do all three, you've got a fraud waiting to happen. So those duties are split, and everything leaves an audit trail.

Interviewer: So if you had to name the thing people get wrong about AP, what is it?

AP: They think it's a clerical function, that AP just keys invoices and pays them. Two things are actually true instead. First, the work isn't the clean invoices, it's the exceptions, the mismatches and the missing POs and the coding, and that's where almost all the effort and the delay sit. Get the front end right, clean POs and clean receipts, and most of the pain disappears, but that depends on procurement and the requesters, not on AP. Second, AP is a control function, not just a processing one. The biggest dollar risks in this whole chain are paying a duplicate, paying a fraudster who changed the bank details, or one person having too much control over the money. So we're guardians of the cash as much as we're processors of invoices. And realistically, a lot of the exception handling and matching is still manual, so it's an area where better automation would pay for itself quickly.

Interviewer: That's a great place to end it. Really helpful, thank you.

AP: Of course, happy to. It's a function people overlook until something goes wrong, so it's nice to walk through what actually goes into it.