A transaction record that keeps its context.
A date and amount rarely explain a private capital transaction on their own. A useful record identifies the entity, original currency, supporting evidence and person responsible for resolving uncertainty. Design those relationships before choosing the storage technology.
Written by the Fundamental View editorial team. Updated 28 October 2026. Examples are fictional and describe operational records, not prescribed accounting entries.
Start with a field dictionary
Agree what every field means before collecting it. Distinguish document date, transaction date, settlement date and reporting period. Define whether an amount comes from a source document, a calculation or an estimate. A value without a definition can produce a different answer in each report.
| Field group | Purpose | Review question |
|---|---|---|
| Record ID and entity | Identify the entry and relevant structure | Could this record be confused with another entity's entry? |
| Dates and counterparty | Retain event and source context | Which date is recorded, and what supports it? |
| Original amount and currency | Keep the source monetary value unchanged | Does the row match the evidence? |
| Reporting conversion | Separate value, FX rate, source, date and status | Can the conversion be reproduced or explained? |
| Category and evidence reference | Connect internal treatment to a source | Can an authorised reviewer retrieve the document? |
| Review state and exception | Distinguish confirmed from unresolved information | Who owns the next action? |
Give review states precise meanings
“Done” is not a useful workflow state unless everyone applies the same test. A small implementation might distinguish drafted, recognised, awaiting evidence, awaiting confirmation and confirmed. The exact labels can differ, but each needs an entry condition and an owner. Recognition is not confirmation; an uploaded document is not necessarily linked evidence; a technically valid crypto transfer is not necessarily an operationally reviewed transaction.
Keep corrections visible according to the actual system's capabilities. Do not imply an immutable audit trail where the configured register only stores the current value. If history matters, specify how changes, reviewers and timestamps are preserved.
Keep original amounts separate from reporting conversions
Where historical FX is in scope, document the source, rate date, currency pair and conversion convention. Retain the original amount. Define how an override is recorded and who reviews it. Available currencies, data rights and treatment of non-business days belong in the implementation specification.
For example, a fictional EUR-denominated row can retain EUR 250,000 while a separate USD field contains the reporting conversion. If the rate is unavailable, the exception should remain visible rather than being silently replaced by a current rate or a plausible estimate.
Crypto evidence needs network context
A transaction identifier is useful alongside network, asset or token, direction, amount and an appropriate explorer reference. If one transaction contains several relevant movements, identify the specific movement. An explorer link alone does not prove beneficial ownership, business purpose or accounting and tax treatment.
Agree how status, timestamps, fees and corrections are represented for each supported network. Do not assume that one network's fields or confirmation rules apply to another.
Internal movements need both sides
A transfer between two entities in the same structure can create two operational rows without being two external cash flows. Define how the rows reference each other and how reporting excludes or treats the internal pair. Otherwise consolidated cash-flow views can overstate activity. The professional accounting treatment remains with the responsible accountants.
Cash-flow reporting starts with consistent inputs
Operational views depend on agreed categories, periods, entity boundaries and review rules. Decide how to represent internal transfers and unresolved entries before relying on an aggregate. A workflow register is not a promise of complete bank reconciliation, consolidated accounting or investment performance measurement.
A repeatable exception review
- List confirmed records without a working evidence reference.
- List rows awaiting human confirmation and identify their owners.
- Review FX gaps and manual overrides separately.
- Check duplicate stable identifiers and duplicate crypto references.
- Match internal pairs and investigate unmatched sides.
- Record the review date and decisions without inventing missing facts.
How Fundamental View approaches the record
Fundamental View uses structured transaction records with stable PCD identifiers, entity and currency fields, linked documents and human confirmation. Google Sheets can serve as the register in the client's own Workspace; SQL migration is a separate implementation decision where scope requires it. The first version does not provide direct bank or custodian connections.
Related working guides
- Follow documents into reviewed records
- Use the evidence and retrieval checklist
- Record a crypto transfer without an invoice
- Assess a register migration
- Agree implementation scope and acceptance
Discuss your workflow
Describe the record-keeping problem you want to solve. Please do not include confidential financial information or documents in the enquiry.
Discuss implementation