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, new coding or rules in Ramp don't update it, so the correction is made in the ERP. Retroactive adjustments in Ramp are only possible for unsynced transactions, which can be re-coded or split before final sync.
Correcting synced coding with Ramp Stack
Ramp Stack makes that ERP correction as a new entry rather than an edit to the original transaction. The team saves its coding guide (common purchases and the account each one belongs to) as a skill under Knowledge > Skills, then adds a recurring GL cleanup task to the close checklist and assigns it to a Stack agent.
Each period, the agent reads general ledger detail from the connected accounting system, lists the entries that no longer match the guide (such as a vendor that landed in two accounts after a rule changed), and drafts reclassification journal entries that move each amount to the right account. The task's approver reviews the workbook and each entry and can approve, edit, or reject it. Approved entries post to QuickBooks Online, NetSuite, or Sage Intacct. The original transactions stay as they were, and the Session Audit Log keeps the trail from each reclass back to them.
Related questions
GL codes can differ for foreign and domestic charges to reflect variations in currency, tax rules, and entity structure. This distinction helps maintain accurate reporting and compliance across regions. Ramp automatically identifies the transaction’s country, currency, and entity, then applies the appropriate GL code and tax settings based on your accounting integrations.
Read moreYes. The vendor points to a likely account, the memo narrows it to the right one, and a reviewer confirms the suggested GL code before it syncs.
Read moreA single transaction can be split across multiple GL codes when it covers different departments, projects, or expense categories. This ensures each portion of the spend is recorded accurately and supports cleaner, more detailed financial reporting.
Read moreManagers usually cannot override accounting codes after month-end close to preserve data integrity. Any post-close adjustments must go through formal journal entries or finance approvals.
Read moreEach line is matched to an existing record first, then categorized, split, or excluded, and the queue is cleared before the books tie to the bank.
Read moreForeign-currency expenses are recorded in the merchant's currency, then translated into the entity's functional currency using the rate and date required by your accounting policy. Card transactions commonly use the cleared or posted amount because that is the final amount charged.
Read more