Skip to main content
Audit gives you a complete record of changes across the platform: who changed what, and when. It is the trail your finance and security teams rely on for control and compliance, and it underpins the SOC2 controls that let you answer “why did this number change?” with evidence, not guesswork.

​
What is tracked

  • Edits to plans, overrides, adjustments, assumptions, and configuration.
  • Who made each change, and the exact timestamp.
  • The before and after of each change, so any number can be traced to its source.
Every write-target table in the platform (entities, overrides, adjustments, rules, assumptions, and config) records to the audit trail, so the coverage is comprehensive rather than limited to a few “important” screens. Pure cache and derived tables, which take no direct user writes, do not generate audit noise; their source tables do.

​
How to use it

1

Find the change

Filter the trail by who, what, or when to locate the edit you are investigating.
2

Read before and after

Each entry carries the prior and new value, so the exact delta is explicit.
3

Trace the number

Follow a number from a report back through the override, adjustment, or assumption that produced it.

​
Common questions

No. It is an append record of changes, which is what makes it a reliable control artifact.
Manual edits to plans, overrides, adjustments, assumptions, and configuration are audited. Ingestion separately preserves a lossless raw payload per source as its own trail; see Connect your data.

​
Troubleshooting

  • I cannot see the audit trail: viewing the audit trail is an admin capability. See Permissions.
  • A number changed and I cannot find why: filter by the entity and time window around when it changed; the override or adjustment that moved it will carry the before and after.
  • A value looks the same in the audit but different on screen: the on-screen figure may be derived from headcount or revenue plans. Trace through the derived posting in GL Mapping.