Short answer. Audit trail software records who did what, when, and to which record. Most business systems already log their own changes well. The gap is the work between them: who was asked for the missing document, which rule version approved the case, who overrode it and why. A workflow audit trail keeps all of that as one record per case.
Updated 12 November 2026. Facts about other products come from their own help pages and documentation when we checked. Floowed is our product, so read that section knowing who wrote it.
What audit trail software records
An audit trail answers six questions about any event:
- Who did it: a named person, an agent or the system, never a shared login.
- What they did: created, changed, approved, rejected, sent, deleted.
- When, with a reliable timestamp.
- Where: which system and which record.
- Before and after: the old value and the new one.
- Why: the rule, the request or the reason given.
Good audit trail software also has a few properties that matter more than any feature list. Ordinary users can't switch it off or edit it. Every entry is tied to a unique identity, because a log full of "admin" proves nothing. It's kept for as long as your obligations require. And it can be exported in a form an auditor will accept.
"Audit trail" and "audit log" get used for the same thing, and most audit log software is sold as audit trail software. Strictly, an audit log is the list of raw entries, and an audit trail is the sequence you reconstruct from them to show how a transaction or a record got to where it is. The distinction matters for one reason: a pile of log entries spread over five systems isn't a trail until something ties them together.
Five types of audit trail software, and what each proves
Your company already has audit trails, probably several. Each one proves something different.
| Type | Example | What it records | What it proves | What it can't show |
|---|---|---|---|---|
| Cloud and infrastructure logs | AWS CloudTrail | Console and API activity in your cloud account. Its event history keeps the past 90 days of management events | The environment was controlled | Anything about the business decision |
| System of record | QuickBooks Online audit log, Salesforce field history | Changes inside that one application | Records weren't changed without a trace | What happened before the data was entered, or in other systems |
| E-signature | DocuSign envelope history and certificate of completion | Who was sent what, who signed, when | The right people signed the document | Whether the terms matched the PO, or what happened next |
| Audit and GRC tools | ZenGRC, Optro (formerly AuditBoard) | Controls, tests, evidence and findings | Controls exist and were tested | The individual case. They collect evidence from the other systems |
| Workflow or case record | Floowed | Every step of a case across systems and people: requests, chases, documents, rule evaluations, approvals, overrides, writes | How this case was decided, and by whom | Infrastructure events. Your ERP still keeps its own log |
The system-of-record trails are often better than people assume. Intuit says the QuickBooks Online audit log can't be turned off and keeps events for two years. Salesforce's standard Field History Tracking covers up to 20 fields per object for 18 to 24 months, and its paid Field Audit Trail extends that to 200 fields, kept until you delete them. AWS documents the 90-day CloudTrail event history and offers trails and CloudTrail Lake for longer retention. Every one of those is a trail of one system.
The gap: the work between systems
Take an ordinary audit question: "Why was this supplier paid into a new bank account in March?"
Your accounting system answers part of it. It shows the bank details on the vendor record changed on 14 March, and which user changed them. It doesn't show that the change request came by email, whether anyone called the supplier back to confirm it, who approved the change in a Slack thread, or that the onboarding checklist sat half-finished in a spreadsheet.
Each of those pieces exists somewhere. Nothing ties them together. So the answer gets rebuilt by hand, by the person who happens to remember, weeks or months after the fact.
That's the job a workflow audit trail does. It doesn't replace the logs inside your systems. It records the case that moved between them: what came in, who was asked, what the rules said, who decided, and what was written where.
What a workflow audit trail should capture
Use this as a checklist, whatever software you use. Example entries are illustrative.
| Field | What it means | Example entry |
|---|---|---|
| Case and trigger | What started the case, and when | Supplier onboarding case opened from a buyer's request in Slack, 9 March 10:05 |
| Every input, with its source | Each document or data pull, and where each value came from | Bank letter, PDF, received by email. Account name read from page 1, line 3 |
| Every request and chase | Who was asked for what, when, and when they answered | Supplier asked for a bank letter in the registered name, 9 March 14:32. Chased 11 March 09:00. Answered 12 March 16:10 |
| Every model step | What a model read or drafted, and which model ran | Model read the bank letter: account name "Harbour Pack Trading" |
| Every rule evaluation | Which rule ran, which version, and the result | "Bank account name matches registered name", version 11: fail |
| Every human decision | Approvals, rejections and overrides, with the person and the reason | Finance approver accepted the exception: trading name proven by certificate |
| Every write | What was created or changed in which system | Supplier created in Xero, 13 March 16:15 |
| Every configuration change | Who changed a rule or a schedule, when, and what testing it passed | Chase interval changed from 48 to 24 hours. Version 8 published after 12 of 12 tests passed |
| Actor on every line | A person, an agent or the system, with a timestamp | On every entry above |
Two rows on that list are missing from most audit trail software: the rule version and the chase. Without the rule version, you can prove a case was approved but not on what basis. Without the chase, you can't explain why a case took eleven days, or show that you asked.
Approval audit trail: who approved what, on what evidence
An approval entry that says "approved by J. Smith, 14:02" is the weakest part of most trails. A useful approval record also shows:
- What the approver saw. The document versions and values in front of them, not just a link to a folder that has changed since.
- Why approval was needed. The rule that sent it to them, such as "price variance above 2%".
- The order. When two approvals are required, which came first, and that the second wasn't given before the first.
- The reason. Especially for an override. "Agreed surcharge for expedited delivery" is evidence. A thumbs-up emoji isn't.
- Separation of duties. The person who requested something shouldn't be the one who approved it. The same goes for rules: the person who builds a change shouldn't be the only one who can publish it.
In Floowed, permissions are set per operation, covering who builds, who approves and who publishes, and every change to an operation is a new version. Approvals happen where people already work, in Slack, Microsoft Teams or email, and land on the case record under the approver's name. For the tools that handle invoice routing itself, see our guide to invoice approval software.
Worked example: the audit trail of one invoice exception
An illustration of what one case's record looks like. A supplier invoice arrives with one line priced above the PO.
| When | Actor | Event | Evidence kept |
|---|---|---|---|
| Mon 08:41 | System | Invoice received in the AP inbox | Original PDF and the email it came with |
| Mon 08:42 | Model | Read supplier, PO number, 12 lines and total | Each value with the page and line it came from |
| Mon 08:42 | Rule, version 5 | Line 7 unit price is 9% above the PO. Tolerance is 2%. Fail | Rule text, version and inputs |
| Mon 08:43 | Floowed | Asked the supplier to confirm the price. Told the budget owner in Teams | Copies of both messages |
| Tue 10:15 | Supplier | Replied: surcharge for expedited delivery, quote attached | Email and attachment |
| Tue 10:16 | Model | Read the quote. Surcharge matches line 7 | Value with its source |
| Tue 10:16 | Rule, version 5 | Price variance needs budget owner approval | Rule text and version |
| Tue 11:02 | Budget owner | Approved in Teams: "expedited delivery agreed with operations" | Approver, time and their message |
| Tue 11:03 | Floowed | Vendor bill created in NetSuite | The record written and its ID |
If an auditor picks this invoice in a sample next year, that table is the answer. No inbox search, no "let me ask Sam". The model's role is visible too: it read two documents. Rules and a named person made the decisions.
Worked example: a supplier bank detail change
Requests to change a supplier's bank details are a well-known route for payment fraud, which makes them a good test of whether an audit trail is evidence or decoration.
Say your rule is: a bank detail change requested by email holds payments to that supplier, and needs a call-back to a phone number already on file, made by someone in finance, before the new details go live. The trail of a case that follows that rule reads:
- Change request received by email, with the new bank letter attached.
- Payment hold set on the vendor in the ERP.
- Call-back task assigned to finance, with the number on file, not the one in the email.
- Finance records the outcome: details confirmed with the supplier's named contact.
- New bank details written to the vendor record.
- Payment hold released.
Compare that with "bank details changed by user 14, 14 March". Both are audit trails. Only one shows the control worked. This is the supplier onboarding operation we cover in our guide to supplier onboarding software.
AI steps belong in the audit trail too
When models read documents and draft messages inside a workflow, the trail needs to cover them like any other actor.
- Record what the model produced, and what used it. "Model read account name X" followed by "rule Y, version 11, used it and failed" is auditable. "The AI approved it" isn't.
- Keep the model out of the decision. Models are probabilistic. If a rule decides, the decision can be replayed and explained. Our guide to AI agent governance goes into why.
- Give agents an identity. An action by an agent should show which agent did it, on whose behalf and under which permissions, just like a person.
- Don't log more personal data than you need. A record of the decision doesn't require copying every document into the log. Floowed minimises personal data in processing and in logs, and redacts personal data in application logs.
Long cases make this harder. A case that runs for three weeks and passes through several people and agents needs one record that survives every handoff. How that works in practice is in AI agent orchestration.
How to evaluate audit trail and audit log software
Ask these in any demo. Ask to see a case that failed a rule, because exceptions are where trails get thin.
- Can it be switched off or edited, and by whom?
- Is every entry tied to a unique person, agent or system, or are there shared logins?
- Does it record the rule and version behind a decision, or only the outcome?
- Does it cover people outside your company, like suppliers and customers who never log in?
- Does it show before and after values, and the document each value came from?
- Can you export one complete case for an auditor in a single step?
- Does it record configuration changes, not only transactions?
- How long are entries kept, and can that match your obligations? Get the answer in writing from the vendor.
Where Floowed fits
Floowed runs your operational cases from intake to outcome. Your rules decide, your people handle the exceptions, and every step is on record.
Floowed isn't a SIEM, a GRC tool or a replacement for the audit log inside your ERP or CRM. Keep those. Floowed keeps the record of the case that moves across them. For every case, that's what was read and from where, who was asked and when, which rule and which version decided it, any override and who made it, and what was written to which system. Decisions, configuration changes and overrides are logged, attributable to the acting user, with version history. You can see how the five stages and the evidence fit together on how it works.
We take security and data privacy seriously. The platform runs on Google Cloud Platform and private deployment is available. Access is role-based with least privilege by default, and data is encrypted in transit and at rest. We're working toward SOC 2 and don't hold a SOC 2 report yet. The details are on our security page.
Pricing is credits, not seats, and every feature is included. You start with $80 of free credits, no card and no sales call, and Team plans start at $100 a month. See pricing.
Frequently asked questions
What is audit trail software?
Audit trail software automatically records a timestamped sequence of actions and changes: who did what, when, to which record, and with what before and after values. Its job is to prove accountability and let anyone reconstruct how a record or a decision got to where it is, without relying on memory.
What is the difference between an audit trail and an audit log?
People use them interchangeably. Strictly, an audit log is the list of individual entries a system writes. An audit trail is the connected sequence that shows how a transaction or case progressed, often drawing on several logs. Many teams have plenty of logs and still no trail.
What should a workflow audit trail include?
The trigger, every input with its source, every request and follow-up, every model step, every rule evaluation with its version, every human approval or override with the reason, every write to a system, and every configuration change, each with an actor and a timestamp.
What is an approval audit trail?
The record of an approval: who approved, what they saw, which rule required the approval, in what order approvals happened, when, and why. For overrides, the reason matters most, because it's what an auditor will ask about.
Do audit trails matter for SOX?
Yes. SOX requires US public companies to maintain internal control over financial reporting. Management assesses those controls every year, and for larger companies the external auditor tests them too. Audit trails are how you show they did, for example that invoices above a threshold were approved by someone other than the requester. The control is the requirement. The trail is the evidence.
How long should you keep an audit trail?
It depends on your obligations: tax rules, industry regulation, contracts and your auditor's expectations. Set a retention policy with your auditor or counsel, then check that each system's retention matches it. System defaults vary a lot, from 90 days of event history to records kept until you delete them.
Can AI agent actions have an audit trail?
Yes, and they should. Record which agent acted, on whose behalf, what it read, what it produced, which rule used that output and what was written where. If a written rule makes the decision rather than the model, the decision can be explained and replayed later.
Where to start
Pick one case from last quarter, ideally an exception, and try to rebuild its full history: who asked for what, who approved, on which rule. If it takes more than a few minutes, or lands on "ask Sam", that's the operation to run with a proper record. Start free with $80 of credits, or talk to us and we'll build the first operation with you.