Acumatica GI Audit Trail — Who Ran What When

Clients ask me to build an "audit trail GI" more often than they ask for almost anything else in the reporting space, and the request usually conflates two very different things: a GI that shows Acumatica's built-in audit history, and a GI that functions as an audit log for the GI system itself — who changed a customer-facing inquiry and when. Both are legitimate; they use completely different data.

Surfacing Acumatica's own change history

Field-level auditing, when enabled on a DAC via the Audit History screen (SM202020), writes to PXAudit-backed tables that you can query in a GI just like any other data source. The relevant tables are Audit (the change batch — user, screen, timestamp) joined to AuditDetail or similar structures depending on version, which hold field-by-field old/new values serialized. In practice, building a readable GI over this is finicky because the detail values are often stored generically rather than as typed columns, so a straight GI join gives you technical field names, not business labels.

Primary table:  Audit
Join:           InnerJoin AuditDetail On AuditDetail.AuditID = Audit.AuditID
Condition:      Audit.TableName Equals 'ARInvoice'
Sort:           Audit.LogDate Descending

For anything customer- or manager-facing, I do not expose the raw audit tables directly. I build a small graph action or a scheduled job that reads audit records for the tables that matter (customer credit limit changes, GL account edits) and writes them into a purpose-built table with human labels, then GI over that. It is more work up front, but the raw audit feed is unreadable to anyone outside engineering.

Who changed the Generic Inquiry — not the data

The second meaning — tracking edits to GI definitions — is not something the GI Designer screen exposes at all. GI definitions live as customization metadata (SiteMap, PXObject/schema tables depending on build), and casual edits made directly in a live GI designer session are not versioned by default. This is the gap that causes the "who changed the sales GI and broke the dashboard" fire drill.

Practically, I set this up two ways depending on client maturity. For teams with a CI pipeline, GI definitions ship as part of the customization package, and git log on the exported package XML is the audit trail — genuinely complete, with author and timestamp from source control. For smaller clients without that discipline, I add a lightweight convention: every GI's Description field carries a one-line changelog ("2026-06-02 JK: added branch filter"), which is crude but beats nothing and takes ten seconds to maintain.

Wrapping up

"Audit trail" GIs split into surfacing Acumatica's built-in field auditing (query Audit/AuditDetail, but expect to need a translation layer for readability) and tracking who changed the GI definitions themselves, which the platform does not audit natively — that has to come from disciplined customization-project source control, not a GI query.