Audit Logging
“Who did what, when, and what happened?” — the question every audit, every incident review and every puzzled Monday morning asks. REDA Financials answers it with the Audit Log: an always-on record of significant actions across the system, with its own tab in the app.
Access you'll need. Audit Log entries are generated by the system — there is nothing to create by hand. Any REDA Financials permission set can open the Audit Log tab and view them; what you see is limited to the records your role can read.
What gets logged
- Accounting events: postings, voids, reversals, approvals and rejections, period closes and reopens.
- Batch runs: every scheduled job writes its outcome — processed, succeeded, failed, with per-record reasons (the entries the Operations cards link to).
- System activity: calculations (aging snapshots), OCR processing, FX syncs, exports.
- Errors: failures are logged with their messages — nothing is silently swallowed, by design.
Anatomy of an entry
Each log record carries: the action (Post, Void, Batch Run, Period Close…), a severity (Info / Warning / Critical), who performed it and when, which record it concerned (linked), and the detail — free-text context, error messages, or a structured summary of field changes. Logging is always on; there is no switch to forget.
Entries are auto-numbered (AUD-…), so every event has a citable identifier. The full field set:
| Field | What it holds |
|---|---|
| Audit Log number | The auto-assigned AUD-… identifier — quote it in tickets and audit workpapers. |
| Action | What happened — one of the action values in the next table. |
| Severity | Info (normal activity), Warning (partial success or something worth a look), Critical (a failure). |
| Performed By / Performed Date/Time | Who and exactly when. Scheduled batches show the platform's automated process rather than a person. |
| Object | The kind of record involved — a sales invoice, a journal entry, a period… |
| Record ID / Record Name | The specific record, linked so one click takes you to it. |
| Entity | Whose books the event belongs to — essential in multi-entity orgs. |
| Additional Info | The free-text detail: error messages, batch summaries like “Processed X | Success Y | Failed Z”, context. |
| Field Changes | A structured before-and-after summary of the fields an update touched. |
| IP Address | Where the action came from — the network-level corroboration auditors ask about. |
The action vocabulary
The Action field uses a fixed vocabulary, which is what makes list views so effective — you can filter to exactly one kind of event:
| Group | Actions | Typical source |
|---|---|---|
| Record lifecycle | Create · Update · Delete | Everyday data entry and maintenance. |
| Accounting events | Post · Void · Reverse · Approve · Reject | The moments a document's accounting status changes hands. |
| Period control | Period Close · Open | Book-closure activity — the events your close checklist should cross-check. |
| Access & output | Login · Export | Who came in, and what data left the system. |
| Automation | Batch Run · Calculate · OCR Processing · FX Rate Sync | The scheduled jobs and system calculations — every run, every outcome. |
Using it well
| Need | Approach |
|---|---|
| Morning operations check | A list view filtered to Action = Batch Run, sorted newest first — outcomes at a glance. |
| Investigating one document | Filter by the record’s name/ID — its whole event history in order. |
| Audit season | Severity and date-range views; export as evidence. Pair with Field History for field-level change detail. |
| Incident review | Critical-severity view — failures with their full messages, ready to diagnose. |
A worked investigation — Meridian's Monday morning
Meridian Properties Group's administrator opens the Operations tab and sees the Cash Receipt Auto-Apply card wearing a Warning outcome. The trail from symptom to fix runs entirely through the Audit Log:
Open the run's entry
The card's View Audit Log link lands on the run's AUD-… record: Action Batch Run, Severity Warning, Performed By the automated process, and an Additional Info summary in the standard shape — processed, succeeded, failed, with a reason per failed record.
Read the reasons
The failures name their causes. The batch's own card description explains the likeliest one — it "respects book closure dates", so receipts whose entity books are closed through the relevant date can't be applied there.
Cross-check the period story
A filter on Action = Period Close shows who closed the entity's books and when — the two entries together are the whole explanation, each with its performer, timestamp and entity.
Fix and catch up
Once the close question is resolved, Run Now on the card re-runs the batch, and a fresh Info-severity entry confirms the catch-up — the incident is now documented end to end, in records nobody can quietly edit.
Common mistakes to avoid
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| Checking the log only when something breaks | Warnings age into mysteries; the context that explains them fades | A daily glance at the Batch Run view — thirty seconds while the coffee brews |
| Diagnosing from the Operations card alone | The card shows the outcome; the reasons live in the log entry it links to | Always click through to the AUD record before deciding what to fix |
| Using the record's Audit Trail tab for cross-record questions | It only shows that one document's history — batch runs and period events won't be there | Start org-wide in the Audit Log, then drill into the record |
| Granting broad edit access to log entries | An editable audit trail is worthless as evidence | Keep the log read-only for everyone but administrators |
| Ignoring Export and Login entries | Data leaving the system and unusual access patterns are precisely what reviews ask about | Include both actions in your periodic review views |
Where to go next
- Field History Tracking — the field-level companion.
- Operations Scheduler Overview — batch outcomes in context.
Frequently asked questions
They’re system-written records intended as evidence — no business process edits them, and access should be read-only for everyone but administrators. Treat retention per your compliance policy.
The record’s Audit Trail tab shows that document’s own history (field changes, steps). The Audit Log is the org-wide event stream — cross-record, batch runs included. Investigations usually start org-wide and drill to the record.
No — it's always on, by design. There is no setting to forget and no gap for an incident to fall through. Postings, batch runs and errors are all captured automatically.
The platform's automated process context — scheduled jobs don't run as a person (and don't consume a user licence). Manual Run Now outcomes are still batch entries; the surrounding timestamps tell you a person triggered the pass.
Yes — Login and Export are first-class actions in the vocabulary, alongside the accounting and automation events. That's what makes the log usable for access reviews, not just accounting forensics.
A structured before-and-after summary of the fields an update touched. For day-to-day field questions ("who changed the amount, from what to what?"), Field History Tracking is the purpose-built companion; the Audit Log adds the event context around it.
Was this article helpful?