SAP FB60

It posts a vendor (supplier) invoice directly in FI accounts payable (without a purchase order), creating the vendor liability.

• Vendor, invoice/posting date, amount.
• G/L account(s) and cost assignment for the expense.
• Tax code and amount.
• Payment terms and text.

• For PO-based invoices, use MIRO (invoice verification) instead.
• Check the vendor’s payment terms/bank data.
• Ensure the correct tax code for the expense.

• Posting period not open.
• Wrong/missing tax code.
• Duplicate invoice (enable duplicate checks).

• Using FB60 for a PO based invoice. It posts cleanly and the purchase order history never sees it, so the goods received clearing account never clears and somebody reconciles it by hand forever.
• Leaving the baseline date at its default. Payment terms calculate from it, so a wrong baseline pays the vendor early or late without anybody choosing to.
• Choosing a tax code to make the document balance. The tax code describes the transaction; picking one for arithmetic produces a return that is wrong in a way nobody notices until an audit.
• One time vendors used to avoid creating master data. No payment terms, no bank details, no history, and the next invoice from the same supplier starts again.
• Reference field left blank. It is what the duplicate invoice check reads, so leaving it empty disables the control you were relying on.