A degenerate dimension is a dimension attribute that is stored directly in the fact table as a column rather than in a separate dimension table — because the attribute has no additional descriptive attributes that would justify maintaining it in a dedicated dimension table. The classic example in finance data warehouses is the GL journal entry number, invoice number, or purchase order reference: each transaction row in the fact table carries an invoice number that identifies the source document, and report consumers may want to filter to a specific invoice or display the invoice number alongside transaction amounts. However, the invoice number itself has no additional attributes in the analytical model — no invoice-level date, amount, or status that isn’t already in the fact table row — so a separate Invoice dimension table would contain only the invoice number as its sole column. A degenerate dimension retains the attribute as a fact table column — dimensionally useful for filtering and display, but with no dimension table overhead.
Common Degenerate Dimensions in Finance
| Degenerate Dimension | Why No Separate Table | Analytical Use |
|---|---|---|
| GL Journal Entry Number | The journal number is the sole identifier; all journal attributes are already in the fact row | Filter to specific journal; group related journal lines |
| Invoice Number | Invoice attributes (amount, date, customer) are already decomposed into fact and dimension columns | Drill-through to invoice detail; filter to specific invoice for audit |
| Purchase Order Number | PO header attributes in separate PO dimension; the number itself has no additional context | Match AP invoices to PO for three-way match reporting |
| Bank Transaction Reference | Reference string used for bank reconciliation matching; no additional attributes | Reconciliation matching key in ARCS or bank reconciliation reports |
| ZATCA Invoice UUID | Clearance UUID from ZATCA Fatoora — identifier only, no additional reportable attributes | Audit trail linking GL transaction to ZATCA clearance record |
Degenerate Dimensions and ZATCA Compliance in Saudi Arabia
The ZATCA Phase 2 e-invoicing mandate introduces a specific degenerate dimension requirement in Saudi enterprise GL fact tables: the Fatoora clearance UUID — the unique identifier assigned by ZATCA to each cleared B2B invoice. This UUID must appear in the GL fact table’s AR and revenue rows as a degenerate dimension, enabling the finance data warehouse to produce a ZATCA audit trail that links each revenue GL posting to its cleared invoice UUID. A tax audit by ZATCA may require the enterprise to produce a report showing all revenue for a specific period, with each revenue line traceable to its ZATCA-cleared invoice — a requirement that is only satisfiable if the clearance UUID is preserved as a degenerate dimension in the finance data warehouse from the point of initial data loading.
What Goes Wrong in Practice
The most common degenerate dimension error is failing to include high-value transaction identifiers in the finance data warehouse fact table — because the source data extract was designed to load aggregated balances by account and period rather than transaction-level detail with document references. When the finance team subsequently requires transaction-level drill-through (finding the specific journal entry or invoice that makes up a specific account balance variance), the data warehouse cannot support it because the degenerate dimension identifiers were never loaded. Finance data warehouse designs must include the transaction identifier columns in the initial scope, even if no reports currently require transaction-level drill-through.
How Loop Wise Solutions Handles Degenerate Dimensions
We include transaction identifier columns — journal entry number, document number, source transaction reference, and ZATCA UUID where applicable — as standard columns in every finance GL fact table we design, regardless of whether current reporting requirements mandate them. The marginal storage cost is minimal; the retrospective cost of adding them after discovery is significant.
Answers before you ask.
A dimension attribute that lives in the fact table itself rather than a separate dimension table — usually a transaction identifier such as an invoice number, journal entry number, or purchase order reference. It is used as a filter or label in reports but has no other attributes worth maintaining in a dimension of its own.
Because a transaction identifier has no descriptive attributes to store — building a dimension table with just the key and nothing else would add joins for no benefit. Keeping it in the fact lets reports group or filter by the identifier directly. Creating an attribute-less dimension would be pointless overhead.
As a label or grouping — listing transactions by invoice number, or filtering to a specific journal entry. It provides the transaction-level identifier that ties fact rows to their source documents. Though it sits in the fact, it functions as a dimension for slicing and identification, hence the name degenerate dimension.
A normal dimension is a separate table of descriptive attributes; a degenerate dimension is a single identifier column inside the fact with no accompanying attributes. One has a rich attribute set worth its own table; the other is just a key used for labelling. The absence of other attributes is what makes it degenerate.