What Is Posting Provenance?

When an auditor asks "why was this journal entry created this way?", you should have an answer. Not a guess. Not "that's how we always do it." An actual, verifiable answer stored in the system.

This is posting provenance.

The Audit Question

Consider this scenario: Your auditor is reviewing a payment received 18 months ago. They ask:

"This $500 payment credited Account 4010 (Assessment Income). Why that account?"

Possible answers:

Bad: "That's the account we use for assessments."

Worse: "I don't know, the person who posted it left."

Good: "Posting Rule PMT_RECV-2 was active at that time, which specified Account Mapping AR_PRIMARY → Account 4010. Here's the rule snapshot stored on the entry."

The third answer is posting provenance.

What Gets Recorded

For every journal entry, a provenance-aware system stores:

Posting Rules Used

• Rule IDs and their versions at posting time
• Transaction type that triggered the rules
• Any conditions or overrides applied

Account Mappings Used

• Which logical roles mapped to which accounts
• The mapping IDs active at posting time
• The effective dates of those mappings

Context Data

• Who initiated the transaction
• What triggered it (payment, invoice, manual entry)
• Timestamp and source system

Why Snapshots Matter

Here's the critical insight: rules change.

In January, your posting rule might say "Assessment payments credit Account 4010."

In March, you might add a new income account and update the rule to "Assessment payments credit Account 4015."

Without snapshots, you lose history. Looking at a January transaction in April, the system would show the March rule—which is wrong.

With provenance snapshots, every transaction carries its own record of "what rules existed when I was created."

The Compliance Implication

SOC 2, financial audits, and board reviews all benefit from provenance:

• Change tracking: See when posting rules were modified
• Accountability: Know who approved which rule changes
• Reproducibility: Explain any historical entry accurately

This isn't about blame. It's about confidence. When you can prove how every entry was created, you can defend your financials.

What "No Provenance" Looks Like

Without posting provenance:

• Old transactions show current rules (anachronistic)
• Rule changes break historical reporting
• Audit responses require manual research
• "Why" questions have no systematic answer

This is how most accounting software works. It's not malicious—it's just not designed for enterprise accountability.

Implementation Reality

True posting provenance requires:

1. Versioned rules: Every change creates a new version
2. Snapshot storage: JSON or related tables capturing state at posting time
3. Immutability: Provenance data cannot be edited post-posting
4. Query capability: Ability to ask "show me all entries using Rule X version 2"

This is enterprise-grade infrastructure. It's why large organizations pay for sophisticated ERP systems.

The Question for Your Software

Ask your current accounting system:

"Show me exactly which posting rule created this journal entry from 14 months ago, and what version of that rule was active at the time."

If the answer involves spreadsheets, emails, or "we'd have to check with accounting," you don't have posting provenance.

Related Concepts

• Why Configuration-Driven Posting Beats Hardcoded Logic - How posting rules should be structured
• Why Audit Trails Fail in Most HOA Software - The broader context of accountability
• What Is Double-Entry Bookkeeping? - The journal entries that provenance tracks