⚖️

Pick a bank account to begin

Reconciliations live under a bank account — select one above.

Reversal dating fix

Reversal entries created before July 2026 were dated the day the edit was made instead of the day of the entry they cancel. That left the original month overstated and pushed a stray reversal into the edit month, so period reports read wrong. This re-dates each reversal to its original entry’s date, so every period nets to zero. Corrected (successor) entries are left alone, and each change is written to the audit log.

Scan for mis-dated reversals Apply fix

Collapse reversal / edit chains (in-place edit backfill)

Before July 2026, editing a posted journal entry (or an invoice) reversed the original and posted a fresh entry, so the general ledger and banking registers show original → reversal → successor triplets for every edit. This backfill makes those edits look the way the new in-place policy does: the original entry takes the successor’s final lines, the reversal and successor entries are removed, and the change is preserved as audit-log rows (what changed, who, when). Deliberate reversals (explicit Reverse, void reversals, and any legacy reverse-and-rework chains) are never touched. Scan first — nothing changes until you apply.

Scan for edit chains Collapse chains

Invoice history — customer names

Invoice history rows written before October 2026 store only a customer id, so the Activity pane cannot say who those invoices were for. This backfill derives the name for each such row from the invoice’s own customer history and the contact’s rename history, and only when both trails prove it. The audit log itself is never changed — names are stored beside it and merged in for display, marked as derived. Anything the trails cannot prove is reported with a reason and left as it is. Scan first — nothing changes until you apply.

Scan for unnamed invoice rows Name the customers