Which date each report uses (transaction_date vs created_at)
Explains which date each report and listing in contable.io uses, and why the accounting date never matches the record creation date.
Updated: April 5, 2026
Every accounting transaction in contable.io has two distinct dates, and knowing which one is used where prevents confusion when reconciling reports.
The two dates
| Field | Meaning |
|---|---|
transaction_date | The accounting date of the economic event. It’s what the user enters on the invoice, receipt or voucher. It decides which fiscal period the transaction lands in. |
created_at | The system date the record was written to the database. Automatic, immutable, used for audit. |
Example: a purchase invoice dated 2026-03-15 entered in the system on 2026-04-02 has
transaction_date = 2026-03-15andcreated_at = 2026-04-02.
Why it matters
If a report uses the wrong date, it can:
- Exclude transactions that belong to the period (entered late).
- Include transactions from previous periods (entered today with an old accounting date).
- Show different balances depending on when you ran the report over the same data.
Project rule (in force since 2026-03-29)
ALL financial reports and listings use transaction_date, NEVER created_at.
This includes:
- Trial balance.
- Financial statements (Balance Sheet, P&L).
- General and daily ledger.
- Auxiliary ledgers.
- Aging report.
- Invoice, receipt and voucher listings.
- Tax reports (VAT and withholding returns).
created_at is only used for:
- Audit (who recorded what when).
- Activity logs (change timeline).
- Operational reports (team productivity, e.g. “invoices recorded today”).
Concrete example
| Action | transaction_date | created_at |
|---|---|---|
| Sales invoice to Customer A | 2026-03-31 | 2026-04-02 |
| Sales invoice to Customer B | 2026-04-01 | 2026-04-01 |
Generating the March 2026 P&L:
- ✅ Correct (
transaction_date): includes Customer A, excludes Customer B. - ❌ Incorrect (
created_at): excludes Customer A (created in April), includes Customer B.
Why this was a change
Before 2026-03-29 some listings used created_at for technical simplicity. This caused month-close issues:
- If you entered an invoice on the 2nd belonging to the previous month, it didn’t appear in the right P&L.
- Balances changed if you refreshed the report after entering a late invoice.
The standardization forces ALL queries to filter by transaction_date, guaranteeing that closing a period doesn’t change retroactively, even if you’re late entering transactions.
User implications
- Always capture the real date of the transaction when creating invoices and vouchers — that’s what counts for your reports and DIAN returns.
- If you record transactions from previous months, make sure the period isn’t closed (closed periods reject new entries).
- The creation date stays as audit history, not fiscal data.
Operational productivity reports
If you need a report of “how many invoices were recorded in the system this week” (regardless of their accounting date), use Settings → Operational reports → User activity. Those do use created_at because the question is operational, not accounting.