SAP Accounts payable

AP records vendor invoices (often via MM invoice verification), manages due dates and payment terms, runs the payment program to pay vendors, and keeps the vendor sub-ledger reconciled to the G/L. It ensures suppliers are paid correctly and on time and that liabilities are accurate.

• Vendor invoices: posting liabilities (direct FI or from MM).
• Payment run (F110): automatic payment of due invoices.
• Payment terms & discounts: managing due dates and cash discount.
• Vendor master (Business Partner): the key data.

Most vendor invoices do not arrive through FI at all. They come from invoice verification in materials management, where they are matched against a purchase order. FB60 posts the ones with no order behind them, such as rent or professional fees.

F-53 posts an outgoing payment manually and F110 runs the automatic payment program, which is how any real business pays. FBL1N lists vendor line items and is where investigations start. F-44 clears an account without new money, for offsetting a credit note against an invoice.

The vendor master is maintained through BP, and its company code view carries the reconciliation account, the payment terms and the payment method. The tables are BSIK for open items and BSAK for cleared ones, views over ACDOCA in S/4HANA.

Half an hour, and it covers the control that AP exists to provide.

1. Post a vendor invoice with FB60. Note the payment terms and baseline date, both copied from the vendor master.
2. Set a payment block on the document, or find one blocked automatically by invoice verification.
3. Run F110 with a proposal. The blocked item is excluded, and the proposal list tells you why.
4. Release the block, run the proposal again, and the item appears.
5. Execute the run. The payment document clears the invoice and posts to the bank clearing account.

The blocking step is the point. AP is not primarily about entering invoices; it is about not paying the wrong ones, and the block is where that control lives.

AP is the finance end of procure-to-pay: MM invoice verification creates the AP liability, which AP then pays. It reconciles automatically to the G/L, and payment posts to bank accounting. Clean vendor master data (BP) underpins it all.

The three-way match happens in materials management rather than in finance, which surprises people. When quantity or price disagree between order, receipt and invoice, invoice verification posts the document and blocks it for payment. Finance then sees a liability it cannot pay until somebody in procurement resolves the difference. See SAP FI GL for the reconciliation account mechanism and SAP FI AR for the mirror image on the customer side.

• Payment methods and runs. Which methods per country, how often the run executes, and who approves the proposal before money moves.
• Tolerances on the three-way match. Too tight and every invoice blocks. Too loose and the control is theatre. This is a finance decision informed by what suppliers actually do.
• Duplicate invoice checking. On, and on which fields. The default combination misses more than people assume, and a duplicate payment is expensive and embarrassing.
• Cash discount policy. Taking early payment discounts is real money and requires the payment run to be frequent enough to catch them.

• Who releases a blocked invoice. Finance sees the block and procurement owns the cause, so the release authority has to be agreed rather than assumed, or blocked items age while each team waits for the other.

Nearly all money leaving a business goes through F110, so understanding its four stages is worth more than any other single thing in AP.

Parameters. You define a run by a date and an identification, then say which company codes, which payment methods, which vendors and up to what date items are due. Getting the next payment date right matters: it decides which items are considered urgent enough to include.

Proposal. The program works out what it would pay and produces a list. Nothing has happened yet. This is the review point, and it is where blocked items, missing bank details and exceptions surface. The proposal can be edited: an item can be blocked, unblocked or moved to a different method before anything runs.

Payment run. Executing the proposal creates the payment documents, clears the open items and posts to the bank clearing account. From here it is real accounting.

Printing and the payment medium. The file for the bank, or the remittance advice for the vendor, is produced separately. An important distinction: the accounting can be complete while the file has not been sent, and reconciling the bank clearing account is what catches that.

Two things go wrong repeatedly. Running without reviewing the proposal, which is how a disputed invoice gets paid. And running the same parameters twice, which is why a run must be either completed or properly deleted rather than abandoned halfway.

Worth being precise about, because it decides which team owns a problem. An invoice for something purchased does not arrive in FI. It arrives in invoice verification in materials management, where it is matched to a purchase order and a goods receipt.

If the three agree within tolerance, the document posts and a payable appears in AP. If they do not, the document still posts and is blocked for payment, with a reason. A price block is a procurement question. A quantity block is usually a receiving question. Neither is resolved in finance, though finance is where the unpaid invoice is visible.

Invoices with no purchase order behind them, such as utilities or professional fees, genuinely do arrive in FI through FB60, and those are the ones where duplicate checking and approval matter most, because no order exists to match against.

Knowing which of the two routes an invoice took is the first question on any AP query, and the document type tells you.

• Duplicate invoices without duplicate checks.
• Wrong payment terms costing discounts or paying late.
• Vendor master issues blocking payment.

• Releasing a block without finding out why it was set. The block is information, and clearing it to make a report look tidy defeats the control.
• Changing payment terms on the vendor master and expecting open items to move. Terms are copied at posting.
• Running the payment program without reviewing the proposal. See the chart of accounts for where those postings land.

• Paying from a statement rather than from open items. The statement is the supplier's view; the ledger is yours, and reconciling them is the job rather than trusting either.

• Treating a blocked invoice as a finance backlog. It is a procurement task sitting in a finance report, and chasing it inside finance is why some blocks survive for months.
• No approval on non-order invoices. Those are the ones with nothing to match against, so they need the strongest control and often have the weakest.

Posting an invoice is straightforward, and configuring payment methods, tolerances and the blocking rules that stop the wrong payment is the part you do in the course.

The habit to build in AP is checking the document type before anything else. It tells you whether the invoice came through invoice verification with an order behind it, or straight into finance with nothing to match against, and those two are investigated in different systems by different teams.