Field History Tracking
Sometimes the question isn’t “what happened” but “what exactly changed — from what, to what, by whom?” That’s field history tracking: on the fields that matter for financial control, every change is recorded as old value → new value, with author and timestamp, visible in each record’s history.
What’s tracked
REDA Financials ships with tracking enabled on the critical fields of its objects — the ones an auditor cares about: statuses, amounts, key relationships (vendor, customer, entity), dates and ownership. The platform allows a bounded number of tracked fields per object, so the selection is curated for control value; your administrator can adjust it where your compliance needs differ.
The curated selection concentrates on five kinds of fields:
| Tracked category | Why it earns a slot | Example question it answers |
|---|---|---|
| Statuses | Status changes are the control moments — draft to posted, approved to rejected | "When did this move to Posted, and who moved it?" |
| Amounts | Money fields are what reviews revolve around | "What was the amount before it was corrected?" |
| Key relationships | Vendor, customer and entity determine whose books and whose money | "Was this bill ever pointed at a different vendor?" |
| Dates | Dates drive periods, due dates and aging | "Who moved the document date, and from what?" |
| Ownership | Who's responsible for the record | "When did this account change hands?" |
Reading a record’s history
Open the record’s history (part of the Audit Trail tab on document pages) and read the trail: Status: Draft → Posted, by K. Sharma, 2 July 2026 12:36. For posted documents the trail is naturally short — that’s the locking doing its job; the interesting histories belong to drafts and master data.
A worked read — Meridian answers an auditor
Meridian Properties Group's auditor picks a posted purchase invoice and asks the classic three-part question: who set this amount, was it ever different, and who posted it? The controller opens the invoice's Audit Trail tab and reads downward: the amount's history shows the original value entered at creation, one correction while the document was still a draft — old value, new value, author, timestamp — and then the status change to Posted. After that, nothing: the lock on posted documents means the trail simply stops, which is itself the answer to "could anyone have changed it since?" The whole exchange takes a minute, and every line of it is system-written.
Where field history sits in the evidence chain
| Layer | Proves | Where to look |
|---|---|---|
| Audit Log | The event — a posting, a batch run, a period close, a login, with actor and timestamp | The org-wide Audit Log tab |
| Field history | The delta — old value to new value, per field, per change | The record's Audit Trail tab |
| The immutable ledger | The accounting — entries no user can edit directly | The Accounting Transactions behind every posting (see Data Security) |
Common mistakes to avoid
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| Expecting history on every field | The platform bounds tracked fields per object — the selection is curated, not exhaustive | Check what's tracked before promising an auditor field-level history of something obscure |
| Using field history to answer event questions | "Did the batch run?" and "who exported data?" aren't field changes | Event questions go to the Audit Log; delta questions come here |
| Reading a short trail on a posted document as missing data | It's the opposite — the lock stopped changes, so there were none to record | Expect rich histories on drafts and master data, quiet ones after posting |
| Adjusting the tracked-field selection casually | A field removed from tracking stops accumulating history you may later wish existed | Change the selection as a compliance decision, documented, with the reviewer's questions in mind |
| Treating field history as the accounting record | It proves who changed a field — the ledger proves what was booked | Use all three layers together; each answers a different question |
Why it matters (a compliance note)
Field history is the fine-grained end of your evidence chain: the Audit Log proves the event, field history proves the delta, and the immutable ledger proves the accounting. Together they give SOX-style reviews what they ask for — who changed what, when, with before-and-after values — without any additional tooling.
Where to go next
- Audit Logging — the event-level companion.
- Data Security & Sharing — the protection stack.
Frequently asked questions
The critical ones on each REDA Financials object — statuses, amounts, key relationships (vendor, customer, entity), dates and ownership. The platform bounds how many fields per object can be tracked, so the shipped selection is curated for control value.
Yes — your administrator can adjust the selection where your needs differ. Treat it as a compliance decision: within the platform's per-object bound, swapping a field in usually means weighing another one out.
On the record — it's part of the Audit Trail tab on document pages. Each row reads old value → new value, with author and timestamp.
Because posting locks the document — a short trail after the Posted status change is the locking doing its job. The interesting histories belong to drafts and master data, where edits are legal.
Field history answers delta questions: from what, to what, by whom, on this record. The Audit Log answers event questions org-wide: postings, batch runs, period closes, logins, exports. Investigations often use both — event first, delta second.
Was this article helpful?