FB60 — Enter Vendor Invoice Without PO Reference
FB60 posts a vendor invoice directly in Financial Accounting with no purchase order behind it. It creates a document with a vendor line hitting the reconciliation account from the vendor master and one or more G/L expense lines. Used for invoices outside procurement scope: rent, utilities, services, freight, subsequent debits. Not the same as MIRO, which matches invoices to a PO.
This page covers FB60, the transaction for posting vendor invoices that have no purchase order reference. It focuses on the diagnostic patterns consultants actually hit: reconciliation account drift, duplicate invoice checks, tax and withholding tax misconfiguration, and the parked-versus-posted confusion. It also covers what tables to check to prove a posting problem and how the transaction maps to S/4HANA's universal journal.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,213 words
Purpose
FB60 posts a vendor invoice directly into FI without any link to a purchase order or goods receipt. The resulting document always has at least one vendor line and one offsetting G/L line, structurally identical to a G/L document except the first line is a vendor account. The one fact that explains most of the confusion around it: the user never chooses the G/L account the vendor line hits. That account is the reconciliation account stored on the vendor master (company code segment), and it cannot be overridden on the entry screen. Anyone trying to force a vendor invoice to a different balance sheet account through FB60 is fighting the vendor master configuration, not the transaction.
When it is used
FB60 is reached for whenever there is no PO behind the invoice: rent, utility bills, professional services not routed through MM-SRV, freight bills, insurance premiums, subsequent debits not tied to a PO line, or manual corrections that logistics invoice verification cannot handle. It sits entirely in FI and never touches the purchase order history tables. When the invoice does reference a PO, the correct transaction is MIRO, which performs three-way matching against PO and goods receipt; using FB60 for a PO-backed invoice breaks the PO's invoiced-quantity tracking and is a common audit finding. On S/4HANA the Fiori app for creating a supplier invoice performs the same posting logic and is the direction new implementations are pushed toward, though FB60 remains functional.
How to use it in practice
- Enter company code, vendor account, invoice date, posting date and reference (external invoice number)
- Enter gross amount and tax code on the header basic data tab
- Enter one or more G/L line items with amount, tax code, and account assignment (cost center, WBS element, internal order) as required by the field status group
- Check the withholding tax tab if the vendor is subject to withholding tax
- Simulate the document and review the debit/credit balance and tax lines before posting
- Post; note the document number returned for tracing
Key data objects
- BKPF - document header: company code, document type (usually KR), fiscal year, posting date, currency
- BSEG - all line items of the document, including the vendor line and every G/L line, before archiving splits it by account type
- BSIK / BSAK - open and cleared vendor line items respectively, the sub-ledger view used for payment proposals and vendor account display
- BSET - tax line items generated from the tax code entered
- WITH_ITEM - withholding tax line items when the vendor is withholding-tax relevant
How to prove it in the data
Pull BKPF filtered on BUKRS and BLART = KR for the date range in question, note BELNR and GJAHR. Use those keys against BSEG filtered on KOART = 'K' to isolate the vendor line and read LIFNR and HKONT; compare HKONT to the vendor's reconciliation account in LFB1-AKONT for the same company code. If the two differ, the vendor master's recon account was changed after this document posted. For tax questions, join the same BELNR/GJAHR/BUKRS into BSET and compare the tax code and amount against what the G/L line in BSEG shows.
ECC vs S/4HANA
The screen and posting logic of FB60 are unchanged on S/4HANA. Underneath, BSEG, BSIK and BSAK become compatibility views over the universal journal table ACDOCA rather than physical tables in their own right, which matters for anyone writing custom reports but not for the end user posting the invoice. The Fiori app for creating a supplier invoice is the strategic front end going forward and adds a cleaner tax and account-assignment layout, but FB60 continues to work and is still commonly used by AP teams.
Common pitfalls and how to diagnose them
- Reconciliation account drift - the vendor's LFB1-AKONT was changed in vendor master maintenance after invoices were already posted against the old account; the general ledger balance for the vendor group no longer ties to the sum of open items in BSIK/BSAK because different documents point to different recon accounts. Check LFB1-AKONT history against BSEG-HKONT on the affected documents before assuming a posting error.
- Duplicate invoice posting - FB60 does not block a second entry of the same invoice number unless duplicate invoice checking is active for the company code and the reference field is populated consistently. When a vendor complains about double payment, first check whether two BKPF documents share the same vendor, amount and reference text, then check whether the duplicate check indicator is even switched on.
- Tax code errors - wrong tax code produces a tax amount that does not match the invoice, or fails entirely for jurisdiction-based tax procedures where the tax code alone is not enough without a valid jurisdiction code on the line. Verify the tax code exists for the country's tax procedure and that BSET actually generated a line before blaming the user.
- Withholding tax silently not calculated - the withholding tax tab shows nothing because the vendor master's withholding tax type is not marked relevant for the company code, or the WT type is not activated at company code level, not because the accountant forgot to enter it.
- Held or parked documents mistaken for posted - a document held (not parked, not posted) exists only in a temporary buffer, not in BKPF, and will not appear in vendor line item display or payment runs; check whether the number the user quotes is a park number rather than a document number before troubleshooting a 'missing' posting.
- Account assignment fields greyed out - the field status group on the G/L account being expensed suppresses the cost center or order field, not a transaction bug; check FS00 for that G/L account's field status group before opening an incident.
Whose problem this is
This is a functional FI/AP problem in almost all cases: vendor master configuration, tax code setup, field status groups and withholding tax activation are all FI configuration, not code or infrastructure. Basis involvement is limited to authorization objects or system performance. ABAP gets involved only when a custom validation, substitution or user exit is altering the posting. A good handover includes company code, vendor number, document number (or confirmation it was only parked), the exact error text, and the tax code and account assignment entered.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/fb60ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.