In many business applications, reference data starts simple.
An item has a price.
A contract has terms.
A rate has a value.
A customer has settings.
At first, it feels natural to store this as one current value.
But serious business software usually needs more than the current value.
It needs to know what value was effective at a specific point in time.
The problem with one mutable current value
Imagine an item price.
If the price changes today, should old documents suddenly look like they used the new price?
Usually not.
A sales document created last month should be able to use the price that was effective last month.
A report should be able to explain which price was active on the report date.
A new document should use the currently effective price.
That is hard to model if the system only stores one mutable current_price field.
When the value changes, history becomes harder to explain.
What are Reference Registers?
In NGB Platform, Reference Registers track effective reference state over time.
They are not Operational Registers.
They are not Accounting entries.
Reference Registers answer a different question:
What value, rule, status, or relationship was effective at a specific point in time?
Examples can include:
- item prices;
- rates;
- contract terms;
- assignments;
- statuses;
- rules;
- configuration values.
In the Trade vertical, the clearest example is item pricing.
Example: Item Price Updates in Trade
In the Trade vertical, item prices are changed through an Item Price Update document.
The document contains:
- effective date;
- item;
- price type;
- currency;
- unit price.
When the document is posted, it writes Reference Register rows.
Those rows represent the effective item price state.
The important part is that the previous value is not silently overwritten.
A new value becomes effective from a specific date.
Current Item Prices
The Current Item Prices report reads from Reference Register state.
It can show the effective price by:
- item;
- price type;
- currency;
- effective date;
- source document.
That gives the system a clear answer to a practical business question:
What price is currently effective for this item and price type?
But the system still keeps the history behind that answer.
Why this matters for documents
A Sales Invoice should not just guess a price from a mutable field.
It should be able to use the price that is effective for its context.
That context may include:
- document date;
- item;
- price type;
- currency;
- customer or other vertical-specific dimensions.
This is why Reference Registers are useful.
They make reference state time-aware, durable, and explainable.
Reference Registers are not Operational Registers
Operational Registers track operational movements and balances.
For example:
- inventory increased;
- inventory decreased;
- quantity was consumed;
- balance changed.
Reference Registers track effective reference state.
For example:
- this item price is effective from this date;
- this rate applies from this date;
- these terms became effective from this date.
Both are important, but they solve different problems.
Reference Registers are not Accounting
Accounting tracks financial ledger effects.
Reference Registers do not replace accounting.
They answer a different question.
Accounting says what financial entries were created.
Reference Registers say what reference value, rule, or state was effective at a point in time.
In NGB Platform, Operational Registers, Reference Registers, and Accounting are peer platform capabilities.
A document action can create:
- Operational Register movements;
- Reference Register changes;
- Accounting entries;
- any combination of them;
- or none of them.
Why Reference Registers matter
Reference Registers help avoid a common problem in business software:
Important business values are treated as mutable fields, and history becomes unclear.
With Reference Registers, the system can preserve time-aware business state.
That makes documents, reports, and future actions easier to explain.
The core idea
The core idea is simple:
Reference Registers track effective business state over time.
In the Trade vertical, that means item prices can change through source documents, become effective from specific dates, and remain available for reports and document processing.
That is one of the reasons NGB Platform is built around documents, actions, durable effects, and traceable business state.
Links
Video: https://youtu.be/Ej0iDW3zyic
GitHub: https://github.com/ngbplatform/NGB
Website: https://ngbplatform.com