RBCO table — Incoming Invoice Account Assignments
RBCO stores account-assignment data for incoming invoice document items in Logistics Invoice Verification. SAP documentation describes RBCO as 'Document Item, Incoming Invoice, Account Assignment' and includes it in the MM_REBEL invoice archiving object. It is not a CO commitment-totals table; it belongs with RBKP, RSEG, and the invoice-account-assignment model.
RBCO holds the commitment values that CO availability control and commitment reporting use to show open purchasing exposure against cost centers, orders, WBS elements and networks. This page covers how the table joins to the purchasing documents that create the commitment, why balances can appear stale, and what actually zeroes a row out.
Published 20 Sept 2026· 925 words
What it stores
One row in RBCO represents the aggregated open commitment value for a specific CO account assignment object, in a given fiscal year and value type, arising from a purchase requisition or purchase order that has not yet been fully consumed by goods receipt or invoice. It is a totals table analogous to the CO actuals totals tables, not a document-level ledger: as a PO or PR is created, changed, reduced by GR/IR, or reorganized, the relevant row is updated or a new row is written rather than the history being preserved line by line. Budget availability control (active availability control on internal orders, WBS elements, cost centers) and commitment line item reports both ultimately depend on values that trace back to this table.
Key fields
- Invoice document number and fiscal year — identify the LIV document.
- Invoice item and account-assignment sequence or block — identify the account-assignment line.
- G/L and account-assignment fields — cost center, order, WBS, or other coding as applicable.
- Amount and quantity distribution — explains split account assignment.
- RBKP and RSEG — provide invoice header and item context.
How it joins the data model
- RBCO-OBJNR maps to the CO object encoded on EKKN's account assignment fields (cost center, order, WBS) rather than a single shared key, so the object type has to be resolved first
- RBCO-EBELN = EKPO-EBELN
- RBCO-EBELN and RBCO-EBELP = EKKN-EBELN and EKKN-EBELP for the account assignment line that produced the commitment
- commitment reduction traces back to goods receipt and invoice postings recorded in EKBE for the same EBELN and EBELP
How to read it safely
Always restrict by MANDT first, then by GJAHR and, where possible, OBJNR or EBELN before pulling rows; this is a totals table that accumulates across the life of every open commitment item in the system and can be very large on systems with high PO volume or long-running WBS elements. Do not attempt a full table scan to reconcile commitments across a company code; start from the CO object or the purchasing document and narrow from there. Because WRTTP and VERSN separate different commitment categories, summing across them without filtering produces numbers that do not match any single report.
How to prove it in the data
Symptom: an internal order or WBS element shows consumed budget against a commitment that no longer appears as an open PO in standard purchasing lists. Select RBCO for MANDT, GJAHR of the current fiscal year, and OBJNR of the object in question. If a nonzero row remains while the referenced EBELN and EBELP in EKPO show the item as deleted, blocked, or fully invoiced in EKBE, the commitment update or carryforward that should have zeroed the row did not run.
ECC vs S/4HANA
RBCO remains part of the S/4HANA Logistics Invoice Verification document model and is included in current SAP MM invoice archiving documentation as Account Assignments. Use it to analyze invoice item account assignments, not CO commitment balances.
Common pitfalls
- Assuming RBCO always mirrors the PO's current open quantity or value in real time; it is updated by the commitment update logic, which can run in batch or be delayed relative to the purchasing transaction
- Deleting or blocking a PO line item does not automatically clear the RBCO row; the reduction happens through account assignment change, goods receipt or invoice posting, or an explicit commitment carryforward or reorganization run
- Treating a zero net balance as proof there is no exposure; reversed or cancelled documents sometimes leave offsetting rows rather than removing the original, so filtering only on GJAHR without WRTTP can hide a real imbalance inside a net-zero sum
- Reading OBJNR as if it always represents the same object type; the same field format is reused for cost centers, orders, WBS elements and networks, and joining to the wrong master table produces a silent mismatch rather than an error
- Explaining a vanished commitment purely from an EKBE goods receipt posting date without checking the fiscal year and value type in RBCO, since backdated or cross-period postings can leave a stale row visible for an extra period
- Expecting an RBCO row the instant a PO is released; where commitment update is configured as a periodic job rather than immediate, a freshly created PO will not show up until the next update run
Whose problem this is
A controlling or project systems consultant responsible for availability control and budget monitoring owns discrepancies in the commitment value shown against a cost center, order or WBS element. The MM buyer's scope stops at whether the purchase order itself is open, closed, blocked or fully invoiced; reconciling that against the CO-side commitment balance is a controlling-side investigation.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/rbcoERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.