Why Time Is the Hardest Problem in Accounting Software

It's March. You notice an invoice from January was miscategorized. You fix the posting rule.

Now every transaction that used that rule—past and future—posts to the new account.

Your January books just changed. In March.

This is the most common failure mode in accounting software, and it stems from a fundamental misunderstanding of time.

The Three Times in Accounting

Every transaction has at least three relevant times:

1. Transaction Date

When the economic event occurred: - The invoice was dated January 15 - The check cleared January 18 - The service was performed January 10-14

This is the date shown on the source document.

2. Entry Date (Post Date)

When the transaction was recorded in the accounting system: - Entered manually on January 20 - Imported from bank feed on January 22 - System-generated on January 31

This might differ from transaction date due to processing delays.

3. System Timestamp

When the database record was created or modified: - Record created January 22 at 14:32:07 - Last modified March 15 at 09:45:22

This is the technical timestamp the system uses internally.

Most systems conflate these. Enterprise systems keep them separate—and use each appropriately.

The "Current Truth" Problem

Consider a posting rule: - Rent payments → debit 6100-Rent, credit 1000-Cash

In February, you realize rent should be split: - 70% to 6100-Rent - 30% to 6105-CAM Charges

You update the rule. What happens to January's rent payments?

Wrong Approach: "Current Truth"

The system re-evaluates all entries using the current rule. January entries now show the 70/30 split.

Problems: - January financial statements changed retroactively - Audit trail shows something that didn't happen - Month-end close is meaningless (it can change later) - Variance analysis compares apples to oranges

Right Approach: "Historical Truth"

The system preserves what actually happened: - January entries stay as originally posted (100% to 6100) - February entries forward use the new rule - The rule change is logged with an effective date

January's books remain stable. They reflect what was done in January.

Effective Dates and Rule Versioning

Enterprise accounting requires configuration that knows about time:

Rule Versioning

Rule: payment_received_processing
Version 1 (effective 2023-01-01 to 2024-01-31):
  Debit 1000-Cash
  Credit 1200-AR

Version 2 (effective 2024-02-01 to present):
  Debit 1000-Cash
  Credit 1200-AR
  Apply 3% early payment discount if paid within 10 days

When processing a transaction from January 2024, use Version 1. When processing a transaction from February 2024, use Version 2.

Even if you process both transactions in March.

Point-in-Time Configuration

When you ask "which rule applies to this transaction?", the answer depends on when the transaction occurred, not when you're asking.

This requires: - Every rule has effective dates - Configuration changes create new versions (not modify existing) - The system can query "what was the rule on date X?"

Backdated Entries

Sometimes you need to record a transaction for a prior period: - Found an invoice dated December 15, entering it in January - Correcting an error discovered after month-end - Recording an accrual for a prior period

The Naïve Approach

Just set the date to December 15 and process normally.

This fails when: - December's posting rules are different from January's - Account mappings have changed - Validation rules have been updated

The Correct Approach

Process with the configuration that was active on December 15: 1. Look up effective configuration for that date 2. Apply those rules (not current rules) 3. Record using the historical rule version 4. Log that this was a backdated entry

The December books now include an entry that follows December rules—even though you created it in January.

Period Close and Immutability

Month-end close should mean something: - January is closed - January's balances are final - No changes without special authorization

But "closed" is meaningless if: - Configuration changes can retroactively affect closed periods - Rule updates silently reprocess old transactions - Historical entries can be edited without audit

True period close requires: - Freezing configuration as of that date - Blocking changes to closed periods (or requiring approval) - Historical entries referencing their point-in-time rules

The Calendar Problem

Time in accounting has additional complexity:

Fiscal Years

Not all organizations run January-December. Fiscal years starting in July, October, or any other month require calendar-aware logic.

Period Definitions

What is "January"? It could be: - Calendar month (Jan 1-31) - Fiscal period 7 (July-based fiscal year) - 4-week period in a 4-4-5 calendar

Cutoff Dates

When does a transaction "belong" to a period? - When the service was performed? - When the invoice was dated? - When payment was received?

The rules vary by transaction type and organizational policy.

The Temporal Audit Trail

For any entry, you should be able to answer:

1. What rules were in effect when this entry was created?
2. What configuration existed at the transaction date?
3. What was the state of the system when processing occurred?
4. Has anything changed since the original posting?

This requires preserving not just what happened, but when it happened in multiple senses—transaction time, processing time, system time.

Why Most Systems Fail at Time

Mutable State

Most systems store configuration as current state: - One row for each rule - Updates overwrite previous values - No history, no effective dates

This works for simple applications. It fails for accounting.

Missing Timestamps

Many systems record when a record was created but not: - When rules were effective - What version of rules applied - When configuration changed

Implicit Assumptions

"Just use today's date" is embedded throughout: - Lookups use current configuration - Validation uses current rules - Reports use current definitions

These assumptions break when time matters.

Complexity Avoidance

Proper temporal handling is genuinely complex: - Bi-temporal modeling (valid time vs. transaction time) - Point-in-time queries - Version-aware processing

Most teams avoid this complexity until it's too late to retrofit.

The "Can You Reproduce It?" Test

Here's how to test temporal correctness:

1. Close a period (say, January)
2. Modify a posting rule or configuration
3. Re-run January's reports

If the numbers change, your system doesn't respect time properly.

More specifically: - Can you reproduce January's trial balance exactly? - Can you explain every entry using January's rules? - Can you prove what rules were active in January?

If any answer is "no," your historical books are not reliable.

The Cost of Getting Time Wrong

Organizations that don't handle time correctly face:

Audit Failures

"Show me the configuration that was active when this entry was created" is a standard audit request. Not being able to answer it is a finding.

Restatement Chaos

When configuration changes affect historical periods, you get accidental restatements. Explaining why February's numbers changed because of a March configuration update is not pleasant.

Reconciliation Hell

When systems disagree about what happened historically, reconciliation becomes archaeology. Which version of the truth is correct?

Legal Exposure

If historical records aren't stable, they're not reliable evidence. In litigation or regulatory examination, unstable books are a liability.

Questions to Ask Your Software

1. If I change a posting rule today, does it affect entries from last month?
2. Can I see what version of a rule was active on any specific date?
3. When processing a backdated entry, does the system use current rules or rules as of that date?
4. After closing a period, can configuration changes affect that period's balances?
5. Can I reproduce a historical report exactly as it appeared when originally run?

If any answer is wrong, time is a problem your software hasn't solved. And unsolved time problems become unsolvable audit problems.

Related Concepts

• What Is Posting Provenance? - Tracking which rules created each entry
• Why Configuration Changes Must Be Audited - Treating config as financial infrastructure
• Why Audit Trails Fail in Most HOA Software - The broader accountability context