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.

Related questions

Can GL codes be applied differently for foreign vs. domestic charges?

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.

Can a single transaction be split into multiple GL codes?

A 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.

Can managers override accounting codes after month-end close?

Managers 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.

How are tax-deductible vs. non-deductible expenses coded?

Tax-deductible and non-deductible expenses are coded under separate GL accounts to ensure accurate tax reporting. This distinction helps you track eligible deductions and maintain compliance during audits. Ramp automatically applies the correct GL code based on your accounting integrations and internal rules.

How do recurring SaaS charges get auto-coded each month?

Recurring SaaS charges are auto-coded through connected bank feeds, vendor recognition, and past transaction patterns. Each charge is matched to the correct GL code automatically, keeping monthly bookkeeping consistent and reducing manual effort. Every month, the system detects the same vendor, payment amount, and frequency, then assigns the correct GL code based on your previous entries. This consistency ensures that recurring software costs appear in the right expense categories across reporting periods.

What happens if two rules match the same transaction?

If two rules match the same transaction, the system applies the rule with the higher priority. This ensures the transaction is coded accurately and avoids duplication or conflicts in your ledger.

On this page