Audit trail requirements in enterprise PSA come from multiple directions simultaneously. Finance needs to reconstruct billing decisions during client disputes. Compliance needs to demonstrate that billing configurations were not changed without authorization during a SOC 2 audit. Legal needs to respond to contract audit rights with timestamped evidence of what rate was applied to which engagement and when. The ERP team needs to trace a GL posting back to the PSA record that generated it. Each of these is a different audit requirement, covering different data, at different retention horizons, with different access controls on the log itself. Understanding which of these the PSA supports natively — and which require supplementary controls — is what makes an audit trail evaluation substantive rather than a yes/no checkbox.
What Audit Trails Need to Cover in Enterprise PSA
A complete audit trail requirement in enterprise PSA spans four distinct categories of events. Most PSA platforms address some of these and not others, and the gaps matter depending on the firm’s specific regulatory and contractual obligations.
The first category is financial record changes: modifications to time entries after submission, expense adjustments, invoice edits, write-downs, and billing adjustments. These are the records most likely to be reviewed during a client dispute or billing audit, and they are the ones where the distinction between who changed what, from what value, to what value, at what time matters most. A system that records only the current state of a financial record — without preserving the prior state and the identity of the user who changed it — is a system that cannot produce a billing audit trail.
The second category is billing configuration changes: modifications to rate cards, billing rules, contract line items, and engagement billing settings. These changes do not affect a single transaction — they affect every transaction that follows. A rate card change that goes unlogged means that if an invoice is disputed three months later, finance cannot demonstrate when the rate changed or who authorized it. At enterprise scale, with dozens of active engagements and multiple billing coordinators maintaining rate configurations, an unlogged billing configuration change is an audit risk that materializes slowly but with large consequences.
The third category is integration transaction history: the record of what was sent to the ERP, when it was sent, in what state, and what happened to it. The fourth is access and permission changes: who modified whose permissions, when, and what the change was.
Financial Record Audit Trail: The Core Requirement
Time entry is the foundational financial record in a PSA. Every billable hour logged becomes a potential billing event, and the audit trail on that record needs to answer a precise set of questions when a dispute arises: who submitted the entry, when, against which project and task type, at which rate, was it approved by whom and when, was it subsequently modified, by whom, from what value, and did it appear on an invoice?
Enterprise PSA platforms handle this through a combination of submission workflow (time entry requires submission and approval before it can be billed, creating a timestamped record of each stage), modification logging (changes to approved time entries are recorded with the original value, the new value, the user who made the change, and the timestamp), and invoice attachment (each invoice line is traceable back to the time entries or milestones that generated it). When a client disputes an invoice line, finance should be able to produce a complete chain of evidence from the original time entry through approval, billing, and invoice generation without assembling it from multiple systems.
Billing Configuration Change History
Billing configuration audit trail is where many PSA platforms fall short. Rate cards, billing rules, and contract terms are typically maintained by a small number of administrators, and changes to them are treated as configuration management rather than financial record changes. The practical consequence is that billing configuration changes are often reversible without trace — an administrator can update a rate, discover the update was wrong, correct it, and the history of the incorrect rate may be lost entirely.
Example: A 290-person IT consulting firm is audited by a client who believes they were overbilled over a six-month period. The dispute centers on whether the correct blended rate was applied to a specific engagement. The billing coordinator believes the rate was correct throughout. The client believes a higher rate was applied for three months before being corrected. Without a timestamped rate card change history, the firm cannot demonstrate that the engagement billing configuration was continuous — the rate either was or was not changed, and neither party can prove it. With an audit trail, the firm produces a log showing the rate card as it was configured on each billing date, with the identity of anyone who modified it and when.
The distinction that matters in billing configuration audit trail is between a change log and a version history. A change log records that a change occurred. A version history preserves the prior state so that finance can reconstruct what any configuration looked like at any point in the past. For billing dispute resolution, version history is the requirement — the log that a change occurred is useful, but the log that shows what was in effect on the billing date of a disputed invoice is what resolves the dispute.
Integration Transaction Audit Trail
Every transaction that the PSA sends to the ERP — AR entries, AP entries, GL journal entries — carries a status that tracks its transmission lifecycle and a cross-reference number that links it to the originating PSA record. The audit trail on these transactions needs to cover whether the transaction was transmitted successfully, whether it was modified after transmission (via integration override), who made the modification, and what the corrected mapping was.
This matters for two audiences. Finance needs it for reconciliation: when an ERP GL entry does not match the PSA record, the integration transaction log is what identifies whether the discrepancy originated in the PSA, in transmission, or in a post-transmission override. Auditors need it for completeness: a SOC 2 auditor reviewing financial reporting controls will ask whether there is a documented record of all transactions sent from the PSA to the ERP, and whether any post-transmission modifications are logged with appropriate authorization. A PSA that allows integration overrides without audit trail creates a control gap that a competent auditor will identify.
Access and Permission Change Logs
The permission model in enterprise PSA is itself a financial control — it determines who can see and modify billing rates, approve time entries, create invoices, and override accounting period settings. Changes to that permission model are therefore financial record events, not just system administration events. When a user’s billing rule access is elevated, or a cost center permission is expanded, or a new user type is granted access to financial configuration, those changes should be logged with the same rigor as financial record changes: who made the change, when, what the prior state was, and what authorization existed for the change.
Access log requirements at enterprise scale go beyond what most PSA platforms provide natively. The audit trail most platforms maintain covers direct user permission changes — who updated whose permissions at what time. What they typically do not cover is indirect access change: a user who gains additional cost center access by restructuring the cost center tree rather than having their permissions directly modified, or a user who is granted a user type that carries broader permissions than their previous individual configuration. These indirect access changes are harder to log because they result from legitimate administrative actions that happen to have permission side effects, but they are the access changes most likely to be exploited intentionally or create unintended exposure accidentally.
Immutability, Retention, and Tamper Resistance
An audit log that can be modified by a PSA administrator is not an audit log — it is a record that someone chose not to modify. The distinction matters for compliance purposes because regulators and auditors evaluating financial controls want evidence that the log reflects what actually happened, not what the firm chose to record. Immutability — the property that log entries cannot be altered or deleted after they are written — is the technical characteristic that gives an audit log its evidentiary value.
- Retention period: financial audit trails need to be retained for the duration the firm’s regulatory and contractual obligations require. For publicly traded firms or government contractors, this may be seven years or more. Ask specifically how long the PSA retains audit log data, whether retention can be extended at the enterprise tier, and whether the log data can be exported for long-term archival in a separate system before it ages out of the PSA’s retention window.
- Tamper evidence: ask whether the audit log is stored in a way that would surface unauthorized modification — whether log entries are cryptographically signed, stored in an append-only data structure, or audited by a separate process that would detect deletions or alterations. Vendors that cannot answer this question specifically are likely storing audit logs in the same mutable database as operational data.
- Log access controls: who can read the audit log, and can those users modify it? The audit log should be readable by auditors and compliance staff and writable by no one — including PSA administrators. A log that administrators can modify provides no assurance to an external auditor.
Questions to Ask During Procurement
Three questions cut through vendor audit trail claims to the operational reality. Each should be answered with a live demonstration, not a feature description.
First: show us a time entry that was submitted, approved, invoiced, and then modified after invoice. What does the audit trail for that entry show, and can we export it? This tests whether financial record modification logging exists and whether it is accessible to finance and compliance teams without vendor involvement.
Second: show us the audit trail for a rate card change on an active engagement. What fields are logged, does the log preserve the prior rate, and how far back can we query? This tests billing configuration audit trail — the category most likely to be absent in platforms that treat configuration as system administration rather than financial record management.
Third: what is your audit log retention policy, is the log immutable, and how would we know if a log entry had been modified? This tests both retention and tamper resistance, and the quality of the answer reveals whether the vendor has engineered the audit log as a compliance control or bolted it on as a reporting feature.
