Do coding rules apply retroactively to past transactions?
Short answer
Coding rules typically apply only to new transactions after they are created. Past transactions may remain unchanged unless updated manually or through specific retroactive adjustments.
Retroactive coding refers to the process of updating GL codes or expense categorizations after a transaction has already been recorded. It allows financial data to stay aligned when rules, account structures, or business policies change over time.
For example, if a company reclassifies its software expenses under a new account, retroactive coding ensures older transactions follow the same updated logic.
When coding rules apply to past transactions
Coding rules apply to past transactions when financial systems detect that a change affects previously recorded data. You may see coding rules apply to past transactions in the following cases:
- Updated GL mapping: When account codes or category names are changed, the system reassigns old transactions to match the new structure.
- Modified expense policies: When your organization updates deductible limits or cost center logic, transactions tied to those policies may be automatically re-coded.
- ERP re-syncs: When a finance platform reconnects or re-syncs with your ERP, new rule logic can refresh older entries for consistency.
- Correction of misclassified data: When historical expenses are reviewed and corrected, updated rules ensure those fixes cascade through past records.
- Integration with new entities: When new business units or subsidiaries are added, past inter-company transactions may be re-coded to reflect the new structure.
Where retroactive updates cannot be applied
Retroactive coding helps maintain consistency across reporting periods, but some transactions remain excluded from updates to protect financial accuracy. These restrictions ensure that once data is verified, it stays unchanged for audit and compliance purposes.
- Closed accounting periods: Once a period is finalized, transactions within it stay locked to maintain the integrity of audited reports.
- Synced ERP data: Entries already pushed to accounting systems or external ERPs are often frozen and cannot be modified automatically.
- Approved reimbursements or payments: Once an expense is reimbursed or settled, its associated coding becomes fixed in the record.
- Incomplete or missing data: Transactions without proper merchant details, receipts, or category context are excluded from retroactive rule application.
- Audit-locked environments: Systems configured for audit readiness prevent edits to verified transactions to preserve version history and traceability.
How Ramp handles retroactive coding
Ramp does not automatically apply new coding rules to past or already-synced transactions. Once a transaction has been exported to an accounting system, any changes to coding or rules must be updated manually in the ERP. Retroactive adjustments in Ramp are only possible for unsynced transactions, which can be re-coded or split before final sync.