For as long as you are the only person entering anything, this question never comes up. The day a nephew, a billing clerk or a part-time accountant gets a login, it comes up within the month — usually as "this invoice used to say something else".
The version of this that does not work
A modified-on date. It tells you the record changed and nothing else: not what changed, not from what to what, and not who did it. In practice everyone stares at it, agrees that yes, something happened, and the conversation ends there.
The other non-answer is a log that lives in the same screen that does the editing. If the thing that records changes can itself be changed, it is a note, not a record.
What a change history has to have
- The field that changed, not just the record — "invoice edited" is not information.
- The value before and the value after, side by side.
- Who did it, by name or email, not a numeric user id nobody can resolve.
- When, to the second.
- No way to delete or edit the history itself, including for the owner.
That last one is the one people argue with, and it is the one that makes the rest worth anything. A history the owner can tidy up proves nothing — including about the owner.
Where the recording should happen
This is a technical detail with a practical consequence. If changes are recorded by the screen you happened to be using, then anything that edits the data another way — a different page, an import, a bulk action — leaves no trace. The gaps are invisible, and they are exactly the changes worth knowing about.
Recording it in the database instead means the trail is written by the same operation that made the change. There is no path that writes the data and skips the log, because they are one event.
How this works in BizGST Pro
Database triggers write to an audit log on twenty-four tables — invoices, customers, items, payments, expenses, stock movements and the rest. The screen that shows it is a read-only viewer: filters, a before-and-after view of the changed fields, and a CSV export. There is no edit and no delete on that screen, for anybody.
The other half: who can do what
A change history tells you what happened. Roles decide what is allowed to happen, and those are different jobs. If everyone who logs in is effectively the owner, the history will faithfully record a mess you could have prevented.
Roles are checked in the database on every query rather than by hiding buttons in the interface. That distinction matters: hiding a button stops someone clicking it and stops nothing else. Each role also carries a plain-language line about what it can actually do — without that the choice is a guess, and the safe-looking guess is to make everyone an admin, which is the exact thing roles exist to prevent.
What to ask before you give anyone a login
Three questions, and they apply to whatever software you use. Can I see what this person changed, field by field? Can they change that record of it? And can I give them a login that does less than mine? If any answer is no, you are not adding a user — you are sharing your account.
What this article does not cover
What any law requires you to retain, in what form, or for how long. Those are set by rules that change, and the sources are the relevant government portal and your accountant. What is above is about being able to answer a question at the counter on a Tuesday.