Skip to content
Fusion Reference

HZ_CUST_ACCOUNTS

Product: HZmaster

The customer account — the commercial (selling) relationship layered on a party; one party can carry several accounts, each with its own account number, status, and type

Notes

The EBS 12.2.2 vestigial ORG_ID is gone entirely — no org column of any kind. CUSTOMER_TYPE is a coded I/R split (internal vs revenue-generating external, page-documented). STATUS decodes through the CODE_STATUS lookup; the A/I value list EBS practitioners expect is not enumerated in the Fusion dictionary. Fusion drops the EBS SALES_CHANNEL_CODE and SUSPENSION_DATE columns.

What the badges mean
Product: EGP
Product: the Oracle product family that owns the object — the short code Oracle's Tables and Views documentation lists as the object owner. Fusion is SaaS, so this isn't a database schema; there's no SQL path to the tables at all (see the quirks guide).
master
Data class: what the table holds — master data, transaction documents, control/configuration, interface/staging, or a documented view.

Structural facts — how the table is partitioned, not a trap by itself

BU-striped (ORG_ID)
Rows are scoped to a business unit. The column is still named ORG_ID, but in Fusion it means business unit, not the EBS operating unit — treat any migrated “operating unit” filter as suspect (see the quirks guide).
Per inventory org
Rows are scoped to an inventory organization via ORGANIZATION_ID — always pair it with INVENTORY_ITEM_ID on item-level joins (see the quirks guide).
Set / ledger / named-BU striped
Some tables stripe by a named column instead of ORG_ID: reference data set (SET_ID — see the quirks guide), ledger (LEDGER_ID on the GL journal tables), or a named business-unit column (PRC_BU_ID / REQ_BU_ID in procurement). The table page’s partition line names the column, and the generated SQL anchors on it — never treat these tables as unpartitioned.
Language-striped
The table carries a LANGUAGE column (a _TL translation table or FND_LOOKUP_VALUES) — one row per language. Filter to one LANGUAGE or a join multiplies rows.

Join & extract hazards — verify before you rely on this

Date-effective
This is an _F table — one row per entity per effectivity window, with EFFECTIVE_START_DATE and EFFECTIVE_END_DATE part of the key. Join without a window filter and every fact multiplies by history (see the quirks guide).
View
This is a documented convenience view, not a physical table. Extract through the BICC data store that fronts its base objects instead of assuming the view lands as-is.
In field listings, the Key chip marks a key field — a member of the documented primary key or of a documented unique index.

Extract access

The delivered surfaces that reach this table — the BICC extract data store (PVO) for bulk extraction and the OTBI subject areas for real-time queries. There is no SQL path to the SaaS database.

  • CrmAnalyticsAM.CrmExtractAM.HzBiccExtractAM.CustomerAccountExtractPVO
    OTBI: Receivables - Customer Real Time

    Customer Account data store — keyed on CustAccountId. The Financials TBI customer subject area is the receivables-side query surface.

    Oracle data-store documentation (opens in new tab)

Fields

12 fields · 1 key

12 fields.

Table fields: position, field name, description, data type, and flags. 12 fields.
#FieldDescriptionTypeFlags
1CUST_ACCOUNT_IDSurrogate key of the customer account — the id AR calls the customerNUMBER
Key
2PARTY_IDThe party this account belongs toNUMBER
3ACCOUNT_NUMBERCustomer account numberVARCHAR2
4ACCOUNT_NAMEAccount description — not the party nameVARCHAR2
5STATUSAccount status — the A/I list EBS practitioners expect is not enumerated hereVARCHAR2
CODE_STATUS
6CUSTOMER_TYPEI for internal, R for revenue-generating external customersVARCHAR2
CUSTOMER_TYPE
7CUSTOMER_CLASS_CODECustomer classification (reseller, education, and so on)VARCHAR2
8ACCOUNT_ESTABLISHED_DATEWhen the account relationship beganDATE
9ACCOUNT_TERMINATION_DATEWhen the account relationship endedDATE
10HOLD_BILL_FLAGWhether bills receivable are on hold for the accountVARCHAR2
11SELLING_PARTY_IDThe party selling to this account — an external-facing organization, not a BU or legal entityNUMBER
12ORIG_SYSTEM_REFERENCELegacy-system customer keyVARCHAR2

Field provenance: hand-curated. 1 key field.

Boilerplate SQL

Starting point for reading the BICC-landed copy of HZ_CUST_ACCOUNTS on Databricks — real DATE columns need no conversion, and the org anchor and the LAST_UPDATE_DATE watermark (the column incremental BICC extracts key on) are already in place. Set your Unity Catalog location, schema, and org values below; they’re substituted into the SQL and the copy button.

Query parameters

4 parameters not filled: <catalog>, <schema>, <CUST_ACCOUNT_ID>, <watermark>

-- ============================================================
-- Table  : HZ_CUST_ACCOUNTS — The customer account — the commercial (selling) relationship layered on a party; one party can carry several accounts, each with its own account number, status, and type
-- Purpose: Column-selected read of HZ_CUST_ACCOUNTS — auto-generated from field metadata
-- Grain  : One row per CUST_ACCOUNT_ID
-- Notes  : Auto-generated skeleton for Oracle Fusion Cloud data landed in your lakehouse by a BICC extract — there is no SQL path to the SaaS database. Column names follow Oracle's table documentation — if your landed data still carries PVO attribute headers, map names first; see quirks #pvo-drift. Dates are real DATE/TIMESTAMP columns — no conversion needed. WHO audit columns omitted (see the quirks guide); the optional LAST_UPDATE_DATE watermark filter supports incremental extracts.
-- ============================================================
SELECT
  t.CUST_ACCOUNT_ID AS "Surrogate key of the customer account — the id AR calls the customer",
  t.PARTY_ID AS "The party this account belongs to",
  t.ACCOUNT_NUMBER AS "Customer account number",
  t.ACCOUNT_NAME AS "Account description — not the party name",
  t.STATUS AS "Account status — the A/I list EBS practitioners expect is not enumerated here",  -- decode t.STATUS via FND_LOOKUP_VALUES (LOOKUP_TYPE = 'CODE_STATUS', LANGUAGE-filtered)
  t.CUSTOMER_TYPE AS "I for internal, R for revenue-generating external customers",  -- decode t.CUSTOMER_TYPE via FND_LOOKUP_VALUES (LOOKUP_TYPE = 'CUSTOMER_TYPE', LANGUAGE-filtered)
  t.CUSTOMER_CLASS_CODE AS "Customer classification (reseller, education, and so on)",
  t.ACCOUNT_ESTABLISHED_DATE AS "When the account relationship began",
  t.ACCOUNT_TERMINATION_DATE AS "When the account relationship ended",
  t.HOLD_BILL_FLAG AS "Whether bills receivable are on hold for the account",
  t.SELLING_PARTY_ID AS "The party selling to this account — an external-facing organization, not a BU or legal entity",
  t.ORIG_SYSTEM_REFERENCE AS "Legacy-system customer key"
FROM <catalog>.<schema>.HZ_CUST_ACCOUNTS t
WHERE
  1 = 1  -- no automatic partition anchor on this table; the filters below are optional
  -- AND t.CUST_ACCOUNT_ID = <CUST_ACCOUNT_ID>
  -- AND t.LAST_UPDATE_DATE >= TIMESTAMP '<watermark>'  -- the column incremental BICC extracts key on
ORDER BY t.CUST_ACCOUNT_ID;

Verified September 2026 · docs release 26C

Column names differ in BICC extracts — see PVO header drift.

Relationships

Diagram of 1-hop neighbors — join details below. FND lookup decode and translation edges are highlighted; they’re the joins newcomers most often get wrong.

Join details

  • HZ_CUST_ACCOUNTSHZ_PARTIESforeign key · N:1
    ON HZ_CUST_ACCOUNTS.PARTY_ID = HZ_PARTIES.PARTY_ID
  • HZ_CUST_ACCOUNTSHZ_PARTIESforeign key · N:1
    ON HZ_CUST_ACCOUNTS.SELLING_PARTY_ID = HZ_PARTIES.PARTY_ID
  • HZ_CUST_ACCT_SITES_ALLHZ_CUST_ACCOUNTSforeign key · N:1
    ON HZ_CUST_ACCT_SITES_ALL.CUST_ACCOUNT_ID = HZ_CUST_ACCOUNTS.CUST_ACCOUNT_ID
  • RA_CUSTOMER_TRX_ALLHZ_CUST_ACCOUNTSforeign key · N:1
    ON RA_CUSTOMER_TRX_ALL.BILL_TO_CUSTOMER_ID = HZ_CUST_ACCOUNTS.CUST_ACCOUNT_ID
  • AR_PAYMENT_SCHEDULES_ALLHZ_CUST_ACCOUNTSforeign key · N:1
    ON AR_PAYMENT_SCHEDULES_ALL.CUSTOMER_ID = HZ_CUST_ACCOUNTS.CUST_ACCOUNT_ID
  • AR_CASH_RECEIPTS_ALLHZ_CUST_ACCOUNTSforeign key · N:1
    ON AR_CASH_RECEIPTS_ALL.PAY_FROM_CUSTOMER = HZ_CUST_ACCOUNTS.CUST_ACCOUNT_ID

Browse more Customers (TCA) tables

More Customers (TCA) tables

Maintained by Summit Analytics, a supply chain analytics practice. The tools and references are free — the consulting is selective.

Part of the Summit Analytics reference library.

Work with the practice

Not affiliated with or endorsed by Oracle. Oracle and Oracle Fusion Cloud Applications are registered trademarks of Oracle and/or its affiliates.