SM Space · Audit & Compliance
Audit Trail Software for Every Change in Your System
SM Space includes audit trail software that records every change, sign-in, error, approval and point-in-time look-up in one trail. Ask what touched a particular invoice, what one person did last quarter, or what changed between two dates. You can seal a period and later prove nothing in it was altered, and hand an auditor a dated copy for their file.
Six separate records, one question. You can seal a period and later prove that nothing in it was altered — and your auditor can run that check themselves.
Last updated: September 2026
One question, six sources
“everything that touched INV-000871”
- 10 Mar 09:12sign-in Signed in · 192.0.2.44 M. Duarte
- 10 Mar 09:14change Amount 12,400 → 14,900 M. Duarte
- 10 Mar 09:14error Save failed · validation retried
- 10 Mar 09:15change Amount 12,400 → 14,900 M. Duarte
- 11 Mar 11:02approval Approved D. Whitfield
six records that always existed — and until now, six screens
Sealed, then checked
Q1 · field changes
- 14 Marseal taken 3a91f0… chained to 7c22be…
- 12 Sepverifyrecomputing…
- ✓intactQ1 unchanged
- ✗mismatch04 Feb – 11 Feb no longer matches
both outcomes, because a check that only ever says “intact” proves nothing
Access with an end date
FY2026 year-end audit
J. Whyte, Marren & Co
from 01 Oct to 15 Nov
16 Nov access ended automatically
the login belongs to the audit, not to the year
A copy for their file
audit-2026-Q1.zip
- 4,902 field-changes.csv sha256 1b0e…
- 812 sign-ins.csv sha256 9fa2…
- 37 errors.csv sha256 04c1…
- 264 approvals.csv sha256 e77d…
- ✓manifest.json seals verified at 12 Sep 14:08
pack fingerprint d41a9c… recorded
↳ and this export is itself in the trail
Above: one question about an invoice answered from six separate records — the sign-in, the field change, the failed save, the retry, the approval and the version it left behind — in one list; a period sealed in March and verified six months later, coming back either intact or naming the exact week that no longer matches; an external auditor’s access ending on its own when the engagement does; and an evidence pack of one spreadsheet per source with row counts, per-file fingerprints, the seal verification at the time of export and its own fingerprint — with the export itself recorded in the trail.
What you can do
- See everything that touched one record, in one list
- See everything one person did, between any two dates
- See the change, who was signed in, whether it errored and who approved it — together
- Know whether a quiet week was a quiet week or a recorder somebody switched off
- Seal a period, and later prove nothing in it was altered
- Let your auditor run that check themselves, without asking you
- Give an auditor access that ends when the audit does
- Export a dated pack with a manifest and a fingerprint for their file
- Decide how long each kind of record is kept
- See exactly what a purge would remove, before it removes it
- Ask any report for what it would have said on a past date
01
One Audit Trail, Six Sources
The system has always recorded what it did. Until this module, it recorded it in six separate places.
Every field change went in one. Every sign-in and failed sign-in in another. Every error in a third. What a record looked like on a past date in a fourth. Every approval in a fifth. And whether somebody switched the recording off in a sixth. Six honest records — and nobody could ask one question across them. “Show me everything that touched this invoice” meant opening six screens and matching timestamps by eye.
Now it is one trail. Ask it by record, by person, or between any two dates. For invoice INV-000871 you get M. Duarte signing in at 09:12 from 192.0.2.44, changing the amount from 12,400 to 14,900 at 09:14, the save failing validation and being retried a minute later, and D. Whitfield approving it the next morning — one list, in time order.
The sixth source cannot be filtered out. A quiet week in the field-change trail means either that nothing happened or that somebody switched the recorder off, and that is the only source that tells the two apart. Every list also says how far back it can see, so an empty result is never mistaken for a quiet period.
- 10 Mar 09:12sign-inSigned in · 192.0.2.44M. Duarte
- 10 Mar 09:14changeAmount 12,400 → 14,900M. Duarte
- 10 Mar 09:14errorSave failed · validationM. Duarte
- 10 Mar 09:15changeAmount 12,400 → 14,900M. Duarte
- 11 Mar 11:02approvalApprovedD. Whitfield
- 11 Mar 11:02historyVersion 4 · what it says from here
- Field changes what a value said before and after three of the rows above
- Sign-ins who was signed in, from where, and who failed to be one of the rows above
- Errors what threw, and what the person was doing one of the rows above
- Approvals who decided, and on whose authority one of the rows above
- Record history what a record looked like on a past date one of the rows above
- Recording switch whether anybody turned the recording off nothing here — and it cannot be filtered out
coverage This trail can see back to 02 Jan 2026. Before that there is no data rather than no activity, and the screen says so rather than showing you an empty list.
One question, six sources, one list. The sign-in, the change, the failed save, the retry, the approval and the version it left behind.
02
Tamper-Evident Records
You can take a seal over a closed period: a fingerprint of exactly what the records said, chained to the seal before it so the chain itself cannot be quietly re-cut.
Months later anybody can run a check that recomputes it against what is in the system now — including your auditor, without asking you. It comes back intact, or it names the exact range that no longer matches. That is the question an auditor actually has and rarely gets a real answer to: could this have been changed after the fact?
Q1’s field changes were sealed on 14 March as 3a91f0…, chained to 7c22be… before it. Verified on 12 September it comes back intact. Verified after somebody edited a February row directly, it comes back naming 4 to 11 February. There is a test in the build that does exactly that — seal, alter a row in the database, verify — and it fails if the check does not catch it.
The first seal for each source says plainly that it starts at the oldest record still held, and claims nothing about the period before. It does not vouch for history it was not there for.
It is tamper-evident, not tamper-proof. Somebody with direct access to the database can change a row. The seal is how you find out.
- Taken14 Marover a closed period
- Digest3a91f0…SHA-256, chained to 7c22be…
- Covers01 Jan – 31 Marno overlap with the seal before, and no gap
— six months later —
Nothing was touched
intact 12 Sep · recomputed over the live rows and it still comes to 3a91f0…
A row was changed afterwards
mismatch 12 Sep · 04 Feb – 11 Feb no longer matches — it names the week, not just the quarter
first seal Starts at the oldest record still held and claims nothing about the period before. It does not vouch for history it was not there for.
Tamper-evident, not tamper-proof: somebody with direct access to the database can change a row. This is how you find out.
03
Auditor Access That Expires
An external auditor needs to see things. What usually happens is that somebody creates them a login, the audit finishes, and that login is still there next year.
Here an audit is a thing with a start and an end. J. Whyte of Marren & Co is given the FY2026 year-end engagement, 1 October to 15 November. On 16 November the access is over, and nobody had to remember.
The access belongs to the engagement in two ways. It ends on its date — after that every audit screen refuses and names the date, rather than showing an empty page somebody might read as “nothing happened”. And it is held to the period: an auditor who asks for a wider range is shown their own period rather than an error, and never the extra rows.
An auditor reaches the audit screens and nothing else. Somebody auditing your company cannot open your staff list. They can read your retention policy and they cannot change it — it is part of what is being audited.
- EngagementFY2026 year-end audit
- AuditorJ. Whyte, Marren & Cooutside the company
- From01 Octand not a day before
- To15 Novand not a day after
- Period they may read01 Jan – 30 Sepask wider and you are shown this, not an error
- 15 Nov Signed in, read the trail, verified the Q1 seal without asking anybody
- 16 Nov Access ended by itself nobody had to remember
- 17 Nov Refused — “this engagement ended on 15 Nov” it names the date rather than showing an empty page
An auditor reaches the audit screens and nothing else. Somebody auditing your company cannot open your staff list.
04
Audit Evidence Packs
Auditors want to take something away.
The export is a ZIP with one spreadsheet per source, plus a manifest listing the filters used, how many rows are in each file, a fingerprint of each file, the seals covering that period and whether they verified at the moment of export, who generated it and the exact time. There is a plain-English README explaining the columns.
audit-2026-Q1.zip holds field-changes.csv at 4,902 rows, sign-ins.csv at 812, errors.csv at 37 and approvals.csv at 264, each with its own SHA-256; a manifest recording that the seals for the period verified at 12 September 14:08; and the pack’s own fingerprint d41a9c… stored on our side — so a pack produced in March can be shown in July to be the pack produced in March.
Nothing is capped. The 500-row limit on the screen is a screen’s limit and has no business in an export.
And taking a copy is itself recorded in the trail, naming who took it and with what filters. The audit trail audits the auditing.
- field-changes.csv 4,902 rows sha256 1b0e…
- sign-ins.csv 812 rows sha256 9fa2…
- errors.csv 37 rows sha256 04c1…
- approvals.csv 264 rows sha256 e77d…
- manifest.json filters, counts, digests seals verified ✓ at 12 Sep 14:08
- README.txt what every column means plain English
pack fingerprint d41a9c… recorded on our side, so a pack made in March can be shown in July to be that pack
in the trail and this export is itself recorded — who took a copy, and with what filters
No row cap. The 500-row limit on the screen is a screen’s limit and has no business in an export.
How SM Space audit trail software compares
The one-line answers buyers usually ask for, and then the one that matters more — what it does not do.
- One trail, six sources Field changes, sign-ins, errors, approvals, record history, and the recorder being switched on or off.
- Ask by record One row’s whole life, in time order, in one list.
- Ask by person One person’s footprint across all six sources.
- Filter by date and actor Between any two dates, by whoever you name.
- Tamper-evident seals Chained and versioned, with no overlaps and no gaps.
- Auditor-run verification Your auditor recomputes the seal themselves, without asking you.
- Access with an end date The login belongs to the engagement, and is held to its period.
- Evidence pack export No row cap, a manifest, per-file and whole-pack fingerprints.
- Retention you set Per kind of record, arriving switched off, with a purge you see before it runs.
- Point-in-time reporting Any report as of a past date, and the difference traced to the changes behind it.
- Cloud Runs in a web browser, nothing to install.
What it does not do. It does not certify you as compliant with anything. No software makes an organisation compliant with a regulation: that depends on your processes, your configuration, your people and your auditor’s judgement. SM Space gives you and your auditor the records and the proof; the judgement stays theirs. The trail also starts when the module did — the first seal for each source records that it begins at the oldest record still held and claims nothing about the period before it existed. And an evidence pack is a download rather than permanent storage: take the copy and keep it in your own file.
How it fits with the rest of SM Space
Nothing here is a separate logging product you switch on. The trail is written by the ordinary act of using the system — a purchase order approved, an employee record edited, a pay run posted.
- Field changes — every value, before and after feeds
- Sign-ins — and the ones that failed feeds
- Errors — and what somebody was doing feeds
- Approvals — who decided, on whose authority feeds
- Record history — what it said on a past date feeds
- Recording switch — if anybody turned it off feeds
- answers Your auditor — their own access, ending on its own date
- answers The evidence pack — a dated copy that proves it is the copy
- answers The seal — proof a closed period did not move
There is no configuration to get wrong, and nothing quietly stops recording because somebody forgot to enable it on a new screen. This module owns none of the six records: it reads what six other parts of SM Space were already keeping, and its own work is the asking, the sealing and the export.
Sign-ins and failed sign-ins come from security and access control. Approvals come from workflow and approvals, with the name of whoever decided and whose authority they used. Record history is the point-in-time engine accounting and finance uses to answer “why did this number change” — any report can be asked for as of a past date, and the difference between two dates traced back to the changes that caused it. Field changes, errors and the recording switch come from the platform’s own tracking in system administration. Reporting and dashboards, Canadian payroll and everything else write into the trail simply by being used.
Who this audit trail software is for
Companies of roughly 20 to 500 people where somebody has asked who changed a figure last March and the honest answer is that you would have to ask around — or where your first real audit is coming and the plan is currently a folder of exported spreadsheets. SM Space is a cloud ERP system: it runs in a web browser, with nothing to install.
Frequently asked questions
- What does SM Space record?
- Six things, in one trail: every change to a field with what it said before and after; every sign-in and failed sign-in; every error; every approval decision; what a record looked like on a past date; and whether anybody switched the recording on or off. You can ask it by record, by person, or between any two dates.
- Can I see everything that happened to one record?
- Yes, and it is the question the module was built for. Ask for invoice INV-000871 and you get the sign-in behind each change, the change itself with the old and new value, any error thrown while it was being saved, and the approval — in one list in time order, rather than six screens you match up by eye.
- Can someone edit the audit trail?
- You would find out. The trail is written by the system rather than typed by people, and you can seal a closed period and recompute that seal later: if a row was altered, the check comes back naming the range that no longer matches. We will not tell you it is impossible to alter — anybody with direct access to a database can change a row. The point is that it is detected.
- How long is the history kept?
- As long as you decide. You set a retention period for each kind of record, and the policies arrive switched off, so installing this module deletes nothing. A purge shows you exactly what it would remove before it removes it, and it seals the rows before deleting them — so the fingerprint and the count survive even though the rows do not.
- Can our auditor get their own access?
- Yes, and it ends by itself. You create an engagement with a start and an end date, and the access belongs to it: after the end date every audit screen refuses and names the date. They see only the period you gave them and only the audit screens — an auditor cannot open your staff list — and they can run the seal check themselves without asking you.
- Does this make us SOX or GDPR compliant?
- No. No software makes an organisation compliant with a regulation: that depends on your processes, your configuration, your people and your auditor’s judgement. What SM Space gives you and your auditor is the records, the proof that they were not altered, and an export you can hand over. The judgement is the audit, and it stays with the auditor.
Ask it what happened last March.
Book a 30-minute demo and we’ll run the seal check on the screen — both ways, intact and caught.
Book a 30-minute demo