Accounts Payable Interview Questions

“I studied commerce and my first job was as a finance assistant in a small distribution company, where I ended up owning supplier invoices because nobody else wanted them. I found I liked it. There's a clear right answer most of the time, and when an invoice is stuck it's usually a small puzzle, a missing goods receipt or a price that changed, that you can solve by talking to the right person. After two years I moved to a shared service centre handling a much bigger volume in an ERP, which taught me matching and payment runs properly. I'd like this role because the volume and supplier mix are more complex, and I want to grow towards handling exceptions and close work, not just data entry.”

“The flow starts before AP sees anything. Someone raises a requisition, procurement turns it into an approved purchase order, and when the goods arrive the warehouse posts a goods receipt, or for services the requester confirms the work was done. AP's job starts when the invoice arrives. We check it's a valid invoice for our company, match it to the PO and the receipt, clear any exceptions, post it, and then it gets picked up in a payment run on its due date. It ends when the payment has cleared and the supplier account is clean. What I need from upstream is a correct PO with the right price and a timely receipt. Most stuck invoices I've seen trace back to one of those two being missing or wrong.”

“In SAP, a PO invoice goes through MIRO. You enter the PO number, the system pulls the lines and the goods receipts, and it checks price and quantity. If something's off it blocks the invoice for payment, and those are later released once the issue is fixed. A non-PO invoice goes through FB60, straight to the vendor account, and I have to pick the GL account, cost centre and tax code myself. In Oracle it's the same idea in the invoice workbench: you either match to the PO or enter distribution lines by hand, then validate, and any problem shows as a hold. The big difference in checks is that a non-PO invoice has no match protecting it, so it needs a proper approval from the budget holder and a careful look at the coding before it posts.”

“A two-way match compares the invoice with the purchase order: are we being charged the agreed price for a quantity we ordered? A three-way match adds the goods receipt, so it also checks that we actually received what we're paying for. Three-way is the normal choice for physical goods, because the biggest risk there is paying for something that never turned up or only partly arrived. Two-way makes sense where there's nothing to receive in a warehouse, like subscriptions or some services, or for low-value spend where the cost of chasing receipts is higher than the risk. Some companies go further with a four-way match, adding a quality inspection, for things like raw materials that have to pass testing before they're accepted.”

“I wouldn't pay the higher price just because the supplier's pushing, because that's exactly what the match is there to stop. First I'd check whether there's a reason: a contract price change, an agreed increase, or extra items like freight on the invoice. Then I'd find whoever covers for the buyer, or their manager, rather than waiting two weeks. If the new price was agreed, they update the PO and the invoice matches and pays. If not, I'd ask the supplier for a credit note for the difference. I'd keep the supplier updated honestly, telling them what's holding it and when I expect an answer. If the supplier's critical and the delay is long, some companies allow paying the undisputed part now, but only if the policy allows it and the approver agrees.”

“I wouldn't post the receipt myself or override the block, because the whole point of the three-way match is that someone who actually handled the goods confirms they arrived. I'd ask the warehouse for the delivery note and to check the quantity, and then ask them to post the receipt in the system for what was actually received. Once that's done the invoice matches and releases on its own. If only part of the delivery arrived, the receipt shows just that, so the invoice stays blocked for the difference until the rest turns up or the supplier sends a credit note. If this site keeps forgetting receipts, I'd raise it with their supervisor and start sending them a weekly list of invoices waiting on receipts, because otherwise the same suppliers end up paid late every month.”

“At my last company a freight invoice came in that passed every system check. It had a new invoice number and a slightly different amount from one we'd paid the week before. What caught my eye was the shipment reference, which was the same as on the earlier invoice. I pulled both and saw the second one was a reissue after the carrier had added a fuel surcharge, but they hadn't cancelled the original. If I'd posted it, we'd have paid the whole shipment twice. I put it on hold, emailed the carrier asking for a credit note for the first invoice, and only posted the corrected one once that arrived. I also suggested adding the shipment reference to our duplicate report for freight suppliers, which the team lead agreed to, and it caught two more over the next quarter.”

“A small packaging supplier called me, really upset, because three invoices were overdue and they had wages to pay. I let him finish, apologised that he'd been left chasing, and took the invoice numbers. While he was on the phone I checked: one invoice had never reached us, and two were on hold because the goods receipt had been posted against the wrong PO line. I told him exactly that, asked him to resend the missing one to our AP inbox, and said I'd have the other two sorted that day. I got the warehouse to reverse and repost the receipts, the two invoices released, and I asked my manager to include them in the next day's run. I called him back to confirm the payment date, and I stayed on it until the third was paid too.”

“I check it's a proper tax invoice first. The supplier's registration number should be valid and active, and our legal name and registration number should be correct, because an invoice addressed to the wrong entity or branch can lose the credit. Then the invoice number and date, a clear description, the taxable value, and the rate and tax amount, which I check actually add up and use the right rate for what we bought. I also make sure we received the goods or service and it's for business use, because personal or blocked items usually can't be claimed. Where the reverse charge applies, the supplier shouldn't charge tax at all and we account for it ourselves. And in some regimes our credit depends on the supplier reporting the invoice on their side, so a mismatch report needs regular follow-up.”

“First I make sure both sides are at the same date, so I pull the supplier's line items from our system to the statement date. Then I compare the balances and match line by line: invoices, credit notes and payments, usually by invoice number and amount. Whatever doesn't match I sort into groups. Timing items, like a payment we made that they hadn't received by the statement date, just need noting. Invoices on their statement that we don't have mean we either never received them or they're stuck on hold, so I request copies and check with the buyer. Credit notes they've issued that we haven't booked are common, and so are small differences from discounts or withholding tax that they haven't recognised on their side. Anything that's a real error, on either side, gets an action and an owner, and I keep the reconciliation on file.”

“I'd start with our records: the payment document, the date, the amount, and which invoices it covered. Then I'd check the bank details it was paid to against the vendor master and the change log. If the details were changed recently, that's a warning sign, and I'd check whether the change was verified. Next I'd confirm with the bank or treasury that the money actually left our account and wasn't returned or rejected. If it went out correctly, I'd send the supplier the remittance advice with the bank reference so their bank can trace it, because often it's been received but applied to the wrong account on their side. If it bounced back, I'd fix the details properly, with verification, and reissue in the next run. If it went to the wrong account, I'd escalate straight away, since the chance of recovery drops quickly.”

“I lean towards accuracy, especially on anything that sends money out, because a wrong or duplicate payment can take weeks to recover, and a payment to the wrong account might never come back. A payment that's a day late is annoying, but I can call the supplier and fix it. That said, I don't think slow is acceptable either. Suppliers rely on being paid on time, and missing close deadlines causes problems for the whole finance team. So I try to get speed from the process instead: clearing holds every day so nothing piles up, chasing receipts early, and knowing which checks matter most. What I won't do is skip a verification step because we're busy, since that's usually when mistakes get through.”

“Most of my experience is in SAP. I posted PO invoices in MIRO and non-PO invoices in FB60, released blocked invoices, and pulled vendor line items in FBL1N for statement reconciliations. I also prepared the payment proposal in F110 and fixed the exceptions it threw up, though a senior colleague ran the final payment and sent the bank file. Before that I spent about a year on a smaller accounting package at a family business, where one person did everything from entering bills to paying them. I haven't used Oracle, but the concepts are the same, invoices, holds, matching and payment batches, so I'd expect to pick up the screens within a few weeks with some guidance.”

“That combination of urgency, a senior name, a brand new supplier and a request to skip the normal process is the textbook pattern for payment fraud, so I'd treat it with caution however real it looks. I wouldn't reply to the email or use any number in it. I'd call the director on the number from our internal directory, or walk to their desk, and confirm they actually sent it. If it's genuine, I'd explain that the supplier still needs to be set up and verified and that an urgent payment still needs the normal approval, and I'd help speed that up. If they didn't send it, I'd report it straight to my manager and IT security and keep the email. Either way no money goes out until the vendor is verified and the payment is approved properly.”

“The vendor master decides where money goes, so it needs strong controls. First, separation: the people who set up or edit vendors shouldn't be the ones posting invoices or releasing payments. Second, a proper request for every new supplier, with an approved requester, registration and tax documents, and bank details on the supplier's letterhead or a bank letter. Any change to bank details gets verified by calling the supplier on a number we already hold, never one from the email asking for the change. Third, a second person approves the change in the system. And fourth, regular review: someone checks the change log every week or month, and we block vendors that haven't been used for a year and merge duplicates, because dormant and duplicate records are where fraud and double payments hide.”

“You make and ship physical products from several sites, so I'd guess most of your spend is materials and freight on purchase orders, plus a long tail of smaller service suppliers. That usually means a high volume of PO invoices where three-way matching does most of the work, and the real effort goes into exceptions: price differences, part deliveries and goods receipts posted late at a site. Freight invoices often don't have a clean PO, so I'd expect some manual coding there. You also import some parts, so there's probably foreign currency and withholding questions on overseas suppliers. That matches my last role quite closely, where I handled the exception queue for two plants, so I'd expect to be useful fairly quickly.”

“I get why they feel that way. From their side, they ordered something, the supplier is chasing them, and AP seems to be the wall. So I try to make it visible that most holds come from a missing PO, receipt or approval, and then make it easy for them to fix. I like sending each department a short weekly list of their invoices waiting on something from them, with exactly what's needed. I answer quickly when they ask about a payment. And when I have to say no, I explain why, for example that we can't pay without a receipt because that's how we avoid paying for things that never arrived. In my experience, once people see AP is trying to get their suppliers paid, not block them, they start sending things right the first time.”

“In my last role, utility bills for about sixty sites came in as separate PDFs and we keyed every one by hand into FB60, coding each to the right cost centre. It took one person most of two days a month, and miscoding was common. I asked the utility providers for a monthly consolidated file, which three of the four agreed to, and built a simple template that mapped each meter to its cost centre so the file could be uploaded as a batch. Finance systems helped with the upload format. Keying time dropped from two days to about half a day, and the controller stopped finding miscoded utility costs in the monthly review. The fourth provider still sends PDFs, but that's a handful of bills.”

“Tolerances let an invoice post even if it doesn't match the PO exactly, as long as the difference is inside a set limit, usually a small amount or a small fraction of the line value, and sometimes both. They exist because rounding and tiny price changes shouldn't stop a payment. The risk is that a loose tolerance quietly lets overbilling through. To test ours, I'd pull every invoice that passed with a difference in the last few months and sort by supplier. If one supplier is always just under the limit, that's a pattern worth a conversation. I'd also check the total value of differences we absorbed, and whether tolerances are the same for a tiny supplier and our biggest one, because a limit that makes sense on small invoices can add up to real money on large ones.”

“When I joined my last team there were around four hundred invoices on hold, some over three months old, and suppliers were starting to stop deliveries. I sorted the list by hold reason first, then by due date and supplier importance. That showed me most holds were missing goods receipts at one site, so I sent the site a list and sat with their storekeeper for two afternoons to post the receipts, which released over a hundred invoices in one go. Next I worked the price differences for our critical suppliers, because those were the ones threatening to stop supply. Small, old items went last. In about five weeks we were down to a normal level. The lasting fix was a weekly report to each site of their missing receipts, which kept the queue from building up again.”

“GR/IR stands for goods received, invoice received. When goods are received against a PO, the system debits inventory or expense and credits GR/IR. When the invoice is posted, it debits GR/IR and credits the supplier. If both happen for the same quantity and value, the line nets to zero. A credit balance means we received something but haven't been invoiced yet, which is effectively an accrual. A debit balance means we've been invoiced for something not yet received. Old items are the problem: a PO that was over-received, a price difference, a duplicate receipt, or a supplier who'll never invoice. Left alone, they overstate liabilities or hide errors. So each month I'd age the open items, chase the ones over a set age with buyers and the warehouse, and clear genuine leftovers with approval, in SAP through MR11.”

“I start with what the system already knows. Goods received against a PO but not yet invoiced sit in GR/IR, so they're covered as long as receipts are posted on time. The gaps are usually services and utilities, where nobody posts a receipt. For those I look at open POs where the work has clearly started, recurring costs like rent, cleaning or electricity where an invoice always comes a few weeks late, and I ask budget holders for anything significant that's happened without a PO. I also check invoices that have arrived in the mailbox but aren't posted yet. Each accrual needs a basis, a contract rate, a last invoice or a quote, and I set a minimum amount so we're not chasing trivial items. They're posted as reversing entries, so they drop out automatically next month when the real invoice lands.”

“Most duplicates I've seen aren't the same invoice entered twice in the same way, because the system catches that. They come from small differences. The invoice number is keyed as INV-0045 once and 45 the next time. The same supplier exists twice in the vendor master, so the check doesn't compare across them. A supplier emails a PDF and then posts a paper copy, and two people enter each one. Or someone makes an urgent manual payment and the invoice still goes into the normal run. So I'd tighten the vendor master to remove duplicates, have one intake channel for invoices, make sure the system's duplicate check is switched on and compares the right fields, and set a rule that manual payments are recorded against the invoice immediately. On top of that, I'd run a monthly report looking for near-matches on amount, date and supplier name before payments go out.”

“Our marketing team was ordering events and printing by email and sending us invoices with no PO, which meant chasing approvals every time, slow payments and angry suppliers. Rather than just rejecting invoices, I met their office manager to understand why. It turned out they found the requisition form confusing and didn't know blanket POs existed. I walked her through it and worked with procurement to set up a blanket PO for their two regular print suppliers. Then we agreed a date after which no-PO invoices would be returned to the requester, not held in AP, and I sent a short guide. Their no-PO invoices fell from most of their spend to a few odd items within two months, and suppliers got paid on time, which the team actually thanked us for.”

“In SAP it's F110, though every system follows the same steps. First I set the parameters: the run date, the next run date so the system picks up everything due before then, the company codes, payment methods and supplier range. Then I run the proposal, which lists what it plans to pay and an exception log for anything it couldn't, like missing bank details or blocked items. I review that carefully: the exceptions, any unusually large payments, suppliers whose bank details changed recently, and debit balances. I can block individual items if there's a reason. Once I'm happy, the proposal goes to an approver, ideally someone outside AP, who releases it. The payment run then posts the entries and creates the bank file, which is sent through the bank portal, often with a second approval there. Afterwards I check the bank confirmation matches the run total.”

“Early in my last job I prepared a payment proposal that included an invoice the buyer had asked us to hold because of a quality dispute. The hold had been agreed by email, but nobody had put a payment block on the invoice in the system, and I didn't check the proposal against our dispute list. I spotted it the next morning when the buyer asked about the dispute. I told my manager straight away, and then called the supplier with the buyer. Because the payment had already gone, we agreed they'd issue a credit note once the dispute was settled and we'd offset it against their next invoice, which happened about three weeks later. Afterwards I suggested a simple rule: any hold request becomes a system payment block the same day, and the proposal review includes a check against the open dispute list. We haven't had a repeat since.”

“First I'd ask treasury for the exact amount available and confirm that the final choice sits with the finance controller or CFO, because that decision shouldn't be made in AP alone. Then I'd prepare a proposal ranked by priority. Tax payments and anything with legal penalties go first, then payments that keep the business running, like critical raw material suppliers, utilities and logistics, especially where a supplier might stop supply. Next come small suppliers who depend on us for cash flow, since a small amount can matter a lot to them. Larger suppliers with longer relationships, and invoices not yet due, can usually wait a few days. I'd show the controller the list with the total at each cut-off point, get sign-off, and then make sure deferred suppliers are told honestly with a new date, rather than letting them find out when the money doesn't arrive.”

“Even a small discount for paying twenty days early is usually worth it, because when you annualise it, that's a much higher return than we'd get leaving the cash in the bank, and often higher than our cost of borrowing. So on the numbers alone, the answer is normally yes. But it's treasury's call on whether we have the cash, so I'd check with them first. If we agree to take it, the real work is making sure we actually capture it. The terms need to be set correctly in the vendor master, so the payment run picks the invoice up on the discount date. And invoices from that supplier need to be matched and approved quickly, because an invoice that sits on hold for two weeks misses the window anyway. I'd also check that the supplier doesn't later claim we paid late and take the discount back.”

“Withholding tax means we hold back part of certain payments and pay it to the tax authority on the supplier's behalf. Rules differ by country. Under TDS-style regimes, for example, the rate depends on the type of payment, such as contract work, rent or professional fees, and the deduction is due when the invoice is booked or paid, whichever comes first, which means advances are caught too. In the system, the vendor master holds the supplier's tax ID and withholding codes, so when I post the invoice it splits the amount: the supplier is owed the net figure and the withheld part sits in a tax payable account. Then someone deposits that by the due date, files the return, and we issue the supplier a certificate so they can claim credit. If a supplier's tax ID is missing, some regimes apply a higher rate, so I check that at setup, not at payment.”

“Every invoice and payment posts to the supplier's account and to the AP control account at the same time, so the total of the aged payables report should equal the control account balance on the same date. I run both at month-end and compare. If they differ, the usual suspects are these. Someone posted a manual journal straight to the control account, which shouldn't be possible if it's set up correctly, as a reconciliation account in SAP, for example. In systems like Oracle, some transactions may not have had their accounting created and transferred to the GL yet. Currency revaluation might hit the GL but not be reflected the same way in the aging report. Or the reports were run at slightly different times with postings in between. I find the difference by comparing period movements rather than balances, fix the cause, and document the reconciliation for review.”