GL coding: How to code every transaction accurately

Good GL coding puts every card charge, bill, and reimbursement on the right account and dimensions before close starts. You already know your chart of accounts. The hard part is the edge cases: splitting one charge across teams, settling two rules that match, fixing past transactions, and coding foreign spend.

Get those four right and close stops starting with a reclass list.

What is GL coding?

GL coding is assigning each transaction to a general ledger (GL) account plus the dimensions your enterprise resource planning (ERP) system requires, such as department, class, location, and custom fields. It happens at the point of spend or invoice entry, with a second check when an accountant reviews before sync. A mistake at any of those points becomes a reclass entry at close.

The fields you code on each transaction usually include:

• GL account
• Department
• Class
• Location
• Custom fields like project or client code

Code all of them at the transaction level and your ERP can report by department or location without manual tagging.

How to assign the correct GL code to every transaction

Four habits keep routine coding accurate and give your edge cases a stable baseline to work from.

1. Map spend categories to GL accounts before money moves

Set a default GL account for each spend type before the first charge arrives. The merchant category code (MCC), the vendor, and the expense type an employee selects all feed that default. When vendor and MCC disagree, trust the vendor, since a general-merchandise MCC can cover office supplies or a server.

Then restrict each cardholder and approver to the GL accounts relevant to their role. A sales rep may only need a dozen travel and entertainment accounts. Give them all 300 and they’ll start guessing.

Every default you set is one fewer decision someone makes at the point of purchase.

2. Require dimensions at the point of spend

Require every dimension your ERP system needs, such as department, project, or cost center, at submission. A cardholder knows which team a dinner was for on the night of the dinner. Three weeks later at close, you're guessing from a receipt.

Automated suggestions should fill blanks and propose values. A value an employee enters or an admin sets should stand because overwriting it throws away the context you asked for. That way, you start close with complete records.

3. Automate the first pass on routine transactions

Let automation code routine spend and send exceptions to people. Recurring software and repeat vendors rarely need judgment, so they're the right place to start. Corporate card transactions suit automated GL coding well because merchant data arrives with the charge.

Maintained rule sets hold up until the chart of accounts or the org chart changes. Then someone has to find every rule that references the old account or department, and any they miss keep miscoding.

Coding that learns from corrections adjusts as you fix transactions. Reclass a vendor once and it codes correctly the next time it appears. Track the share of transactions that sync without edits to see whether your first pass at GL coding is working.

4. Review exceptions weekly before close

Review flagged transactions every week so close only handles what came in during the last few days. Give each trigger a set value so reviewers don't rely on instinct:

• Amounts at or above your materiality threshold, such as $1,000 for card spend or $5,000 for bills
• Transactions with any required dimension left blank
• GL accounts outside the spend type's default, such as a card charge coded to fixed assets
• First transactions from a new vendor
• Approver edits that changed the default GL account
• Split lines that don't sum to the original amount

A weekly exception queue leaves close time for accruals and reconciliations.

How to split a transaction across multiple GL codes

Split a transaction when one charge or invoice covers costs that belong to different accounts or teams. The steps stay the same whether the split is two lines or 10.

1. Decide the split basis

Pick the basis before you edit the transaction:

• Amount: Use it when each portion has a known dollar value. A $4,800 software invoice might include a $3,000 engineering seat block and a $1,800 sales add-on.
• Percentage: Use it when teams share a cost by headcount or usage. One conference charge could split 50/30/20 across three teams.
• Line item: Use it when the invoice itemizes costs that map to different GL accounts. Booth fees and attendee passes are a common example.

Record the basis in the transaction memo so the next reviewer can repeat it.

2. Split into lines, each with its own GL and dimensions

Give each split line its own GL account, department, and location, plus any custom fields your ERP requires. The lines must sum to the original transaction amount, down to the cent. A split that's off by a penny can fail to sync or leave a variance on your card reconciliation.

3. Handle tax, fees, and foreign exchange (FX) on split lines

Allocate sales tax to the lines it applies to, in the same proportion as their costs. Put card fees and foreign transaction fees on their own line in your fee GL account so they don't inflate department spend.

Percentage splits often create fractions of a cent. Round each line and put the remainder on the largest line, so a $1,000 charge split three ways becomes $333.34, $333.33, and $333.33. Use that rounding convention on every split.

4. Sync and confirm the split posted as separate lines in the ERP

After sync, open the entry in your ERP and check for one line per split, each with its own account and dimensions. If a line is missing a required field, the sync can fail or post incomplete.

Take a $3,000 conference invoice that covers a marketing booth plus passes for two teams in two offices.

If the ERP entry doesn't match your split line for line, fix it before close.

What happens when two coding rules match one transaction?

Two rules can match the same transaction when their conditions overlap, and each may suggest a different GL account. A vendor rule might send all AWS charges to Hosting while a department rule sends Engineering spend to Software. An engineer's AWS charge matches both.

Tools settle these ties in different ways, some by rule order and some by specificity. Check how yours works before you trust its output, then work through the conflict:

1. Find the conflicting transactions: Filter the last 90 days for one vendor coded to more than one account. Add any transactions reviewers edited after coding.
2. Decide the winning value: Choose the account that describes what the spend is. For AWS, that's usually Hosting no matter which department pays.
3. Remove or narrow the overlap: Merge the two rules, or add a condition so only one applies. Excluding AWS from the Engineering rule would do it.
4. Confirm future transactions code correctly: Check the next 10 matching transactions, or a full week of activity. Close the issue only when both look right.

Look in your coding tool's admin settings for where you can see which value applied to a transaction and why. In Ramp, admin-set values are respected, and the Accounting Agent learns from the corrections you make. Fixing overlaps at the source ends the monthly cycle of correcting the same charge.

Do GL coding changes apply retroactively to past transactions?

No. Changes to how you code transactions apply going forward, and past transactions keep their original coding. Ramp's Accounting Agent doesn't rewrite historical codings, and it doesn't overwrite values employees or admins entered.

How you fix past transactions depends on whether they've synced to your ERP:

1. Identify the affected period and transactions by vendor or date range.
2. Recode anything that hasn't synced yet.
3. For synced transactions, prepare a reclassifying journal entry in your ERP.
4. Document the reason, the approver, and the accounts involved for audit.

A chart-of-accounts change can leave dozens of synced transactions that need reclassing. Ramp Stack's agents can prepare those reclass journal entries and other GL cleanup for accountant review. Nothing syncs to your accounting system until you approve it.

Edit before sync whenever you can, because every synced fix costs a journal entry.

How to code foreign vs. domestic transactions

Foreign spend codes cleanly once you make three decisions and apply them every time.

1. Decide whether location or a separate GL account carries the distinction

Use a location or region dimension to mark foreign spend when your reporting allows it. Separate domestic and international GL accounts double your travel and meals accounts, and each new country tempts someone to add more.

Default to the dimension and add accounts only when a tax or statutory need requires them.

2. Code FX fees and foreign transaction fees consistently

Pick one GL account for foreign transaction fees and bank fees, such as Bank and merchant fees, and code every fee there. If some fees land in Travel and others in Bank fees, neither account shows what foreign spend costs you. One fee account turns FX costs into a single number you can track.

3. Record the amount in your functional currency

Code the amount that settled in your functional currency, matching your card statement or bank feed. Keep the original currency and amount on the record in a custom field or the receipt. That lets anyone trace a €450 hotel bill to the $487.62 charge it became.

Coding the settled amount keeps your card reconciliation tied to the statement.

Common GL coding mistakes

Four GL coding habits create a lot of avoidable reclasses at close.

Letting rules go stale after chart-of-accounts changes

When you retire or rename an account, rules that point to it keep sending spend there or break the sync. Update your coding logic as part of the same chart-of-accounts change.

Waiting until close to code transactions

Coding weeks after a purchase means rebuilding context from receipts and memory. Require dimensions at submission so the person who made the purchase supplies the details.

Overwriting the cardholder's context without a review trail

When a reviewer changes a cardholder's coding with no note, the next person can't tell which value was right. Log every override with a reason so your audit trail explains itself.

Fixing synced transactions without a journal entry

Editing a synced transaction in your spend platform can leave it out of step with the ERP. Post a reclassifying journal entry so both systems agree.

Close your books faster with Ramp's Accounting Agent

Split charges, overlapping rules, and foreign fees are where GL coding breaks down. Each one that slips past review becomes a reclass you handle at month-end.

Ramp's Accounting Agent codes every transaction across GL, department, class, location, and custom fields the moment it posts. It sends only the exceptions to you for review, so you can close your books 3x faster.

Here's what GL coding looks like with Ramp's Accounting Agent:

• Auto-codes more of your volume: You get 3.5x more transactions auto-coded than with legacy or rules-only tools. Every decision shows a confidence level and rationale you can override, so your audit trail stays complete.
• Moves routine spend through a zero-touch lane: Auto Mark Ready and Auto Sync carry in-policy transactions from swipe to your ERP without manual handoffs.
• Surfaces what needs your judgment: Smart Review and Suggested Actions flag the exceptions, so review time goes to the transactions that need it.
• Learns from your corrections: Each override improves future coding. Employee-submitted and admin-set values stay as entered, and past codings stay untouched.
• Prepares cleanup with Ramp Stack: Stack's agents draft reclass journal entries and GL cleanup for accountant review, and nothing syncs without your approval.

Try an interactive demo to see how Ramp codes every transaction for you, and why more than 85,000 businesses use Ramp.