FB75 — Enter Customer Credit Memo
FB75 posts a customer credit memo directly in FI using a single-screen fast entry layout, the credit-memo counterpart to FB70. It creates a new open item on the customer account; it does not automatically net against the original invoice unless the invoice reference fields are filled in, which is the single most common source of confusion and unreconciled open items.
This page covers FB75, the FI transaction for posting a customer credit memo outside the SD billing flow. It focuses on when to use it instead of an SD-based credit process, the tables the posting writes, and the recurring diagnostic problem of credit memos sitting open instead of clearing against the invoice they were meant to offset.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,198 words
What it does
FB75 posts a customer credit memo directly in Financial Accounting, bypassing SD billing entirely. It is the credit-side mirror of FB70 (customer invoice), sharing the same single-screen fast entry layout: a header block, a customer line, and one or more GL or tax offsetting lines. The structural fact that explains most confusion around it is that FB75 does not, by itself, net the credit against any existing debit invoice. It simply creates a new open item with a credit balance on the customer account. Whether that item offsets a prior invoice depends entirely on whether the invoice reference fields (assignment to the original document) were populated at entry. Leave them blank and the credit memo and the invoice both sit open, visible separately on the account, until someone clears them manually.
When it is used
FB75 is used when Accounting needs to issue a credit to a customer that did not originate from a sales order or billing document - a pricing correction agreed outside SD, a manual rebate, a write-off adjustment, or a correction to a prior FI-only posting. It sits in the pure FI layer of the accounts receivable process, parallel to but separate from the SD credit memo request and billing flow. If the credit traces back to a sales return, a billing block correction, or anything with a preceding sales document, the correct route is the SD credit memo process, not FB75, because posting it in FI orphans the correction from the SD document flow and complicates later reconciliation between SD and FI.
How to use it
- Open FB75, enter header data: document date, posting date, document type (typically the dedicated credit memo type), company code and currency
- Enter the customer line: customer number, credit amount, tax code, and if the credit is meant to offset a specific invoice, populate the invoice reference / assignment fields on that line
- Enter the offsetting GL line(s): revenue reduction or expense account, amount, and any required cost center or profit center for CO account assignment
- Use document simulation to confirm the debit/credit balance, tax calculation, and CO account assignment before posting
- Post the document and record the resulting document number for downstream clearing or audit reference
Key fields
- BKPF - document header: document type, posting date, fiscal year, document number
- BSEG - line items for both the customer line and the offsetting GL/tax lines, including amount, tax code, and invoice reference fields
- BSID - open customer items, where the credit memo appears until cleared
- BSAD - cleared customer items, where the credit memo moves once matched against an invoice or another item
- COBL-linked CO document - created when the offsetting line carries a cost center, profit center or other account assignment
How to prove it in the data
Pull BKPF filtered on company code and document type (the credit memo type in use, plus posting date range) to get the candidate document numbers. Join to BSEG on company code, document number and fiscal year, filter to the customer line (account type D) and check the credit indicator on the amount. Check the invoice reference fields on that line - blank means the credit memo was never linked to an invoice at posting. Then check BSID for that customer: if the credit memo and the target invoice both still appear, they were never cleared; if the credit memo has moved to BSAD, it has been offset.
ECC vs S/4HANA
On S/4HANA the posting still writes to BKPF and BSEG for compatibility, but the line items are also reflected in the universal journal, which is what most reporting now reads from. The posting logic, screen layout and the invoice-reference behavior described above are unchanged. Fiori apps covering incoming credit memo creation exist as an alternative front end for the same underlying posting, but FB75 itself remains fully usable and is not deprecated.
Common pitfalls
- Unlinked open item: the credit memo was posted without the invoice reference field filled in, so it sits open alongside the invoice it was meant to offset rather than netting against it. Confirm by checking the reference fields on the BSEG customer line; the fix is a manual clearing transaction against the invoice, not reposting the credit memo.
- Tax code mismatch: the credit memo uses a different tax code than the original invoice, producing a tax report discrepancy even though the net receivable is correct. Compare the tax code on the credit memo line against the original invoice line.
- Wrong document type or number range: using the wrong document type breaks workflow approval rules or dedicated reporting that filters by credit memo type, and the posting looks correct but is invisible to processes expecting the standard type.
- Missing or wrong CO account assignment: the offsetting GL account is cost-element relevant and either fails validation or silently defaults to a substitute cost center. Check the account assignment on the GL line against the default assignment configuration for that account.
- Confused with reversal: FB75 is sometimes used as an informal way to undo a wrongly posted invoice instead of a proper reversal. This leaves the original erroneous invoice document still valid in the audit trail and produces two open items that must both be cleared, rather than one reversed document. When the intent is to cancel a posting error, the correct tool is a document reversal, not a fresh credit memo.
- Currency and rounding differences: when the credit memo currency or exchange rate differs slightly from the original invoice, small rounding differences appear on clearing. Check the amount in document currency on both documents before assuming a data error.
Whose problem this is
This is a functional AR/FI issue in the first instance. A good handover includes the document number, the invoice it was supposed to offset (if any), the tax code used, and whether a CO account assignment was involved. Escalate to Basis only if the problem is an authorization or workflow release step; escalate to FI-CO configuration if the default account assignment logic itself is wrong.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/fb75ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.