GL coding is the practice of assigning a general ledger account code to a financial transaction so your accounting system knows what the money was for. A GL code is the alphanumeric identifier of one account in your chart of accounts, and in many charts it carries several segments, for example entity, department and expense type, so a single code records both what was bought and which part of the business bought it.
Every invoice, receipt and card charge gets one. Get the codes right and your income statement, your budget variances and your close all work. Get them wrong and the numbers look fine while telling you the wrong story, which is worse. Here is what the codes actually are, the ones you will use most, the two questions people get stuck on, and how teams automate the assignment without losing control of it.
What is a GL code?
A GL code is the unique identifier for a single account in your chart of accounts. It classifies a transaction into a category the ledger recognizes: cash, accounts payable, software subscriptions, travel, professional fees, and so on. Most systems use numbers, some use letters and numbers, and the length depends entirely on how much detail your chart of accounts is built to carry.
A short code like 6200 might simply mean "software and subscriptions." A segmented code like 6200-300-US might mean the same account, charged to the marketing department, in the US entity. Neither is more correct. The segmented version gives you departmental reporting without extra work; the short version is faster to maintain and harder to get wrong.
What does GL coding mean?
GL coding means the act of choosing that code for a given transaction and attaching it to the record before it posts. On a supplier invoice it happens after receipt and before approval. On an employee expense it happens when the report is submitted or reviewed. On a company card charge it happens when the transaction is reconciled.
The word "coding" is doing a lot of work there, because it is rarely just one field. A properly coded line usually carries the expense account, a cost center or department, and depending on your setup a class, location, project or job. People say "code it to 6200" and mean all of those dimensions together.
What is GL coding in accounts payable?
In accounts payable, GL coding is the step between receiving a supplier invoice and approving it for payment. Someone reads the invoice, decides which account each line belongs to, adds the department or cost center, and routes it. Only then can the invoice be approved, posted and paid.
It is the slowest step in most AP workflows, and not because it is difficult. It is slow because it requires context that only certain people have. Whoever handles the AP inbox often cannot tell whether a $4,000 agency invoice is advertising, professional services or contract labor without asking the person who commissioned it. Multiply that by a few hundred invoices a month and coding, not data entry, is what makes the close drag.
How do you code an invoice, step by step?
- Capture the document. Get the vendor, invoice number, date, amounts and line items off the page, either by keying them in or by reading them automatically.
- Split it into lines. One invoice frequently spans more than one account. A vendor that bills you for a subscription and an onboarding fee needs two codes, not one.
- Assign the expense account. Pick the GL account each line belongs to from your chart of accounts.
- Add the other dimensions. Cost center or department, then class, location, project or job if your ledger uses them.
- Confirm the period and tax treatment. Decide whether the cost belongs to this period or accrues to another, and how sales or use tax is handled.
- Route and post. Send it to the approver with authority for that account and amount, then post the coded record to the ledger.
What are the most common GL codes?
There is no legally mandated numbering scheme in the US. What exists is a widely used convention that most accounting systems ship with by default, and it is worth knowing because it makes an unfamiliar chart of accounts readable at a glance.
| Number range | What it holds | Examples |
|---|---|---|
| 1000 to 1999 | Assets | Operating cash, accounts receivable, prepaid expenses, equipment |
| 2000 to 2999 | Liabilities | Accounts payable, credit cards payable, accrued expenses, deferred revenue |
| 3000 to 3999 | Equity | Common stock, additional paid-in capital, retained earnings |
| 4000 to 4999 | Revenue | Product revenue, services revenue, discounts and refunds |
| 5000 to 5999 | Cost of revenue | Hosting, payment processing fees, contractor cost of delivery |
| 6000 to 6999 | Operating expenses | Salaries, rent, software, travel, marketing, professional fees |
| 7000 to 7999 | Other income and expense | Interest income, interest expense, foreign exchange gain or loss |
The exact numbers inside each range are yours to set, and they vary between companies even in the same industry. Treat the table as a map of the neighborhood, not as your street address. If you are inheriting a chart of accounts, export it and read it once end to end before you code anything against it.
Within operating expenses, the accounts that see the most traffic in a typical US business are software and subscriptions, travel, meals and entertainment, professional fees, advertising, office supplies, insurance, utilities and payroll-related costs. Those few accounts absorb the large majority of coded lines, which is exactly why automating the repetitive part pays off.
What is the GL code for software?
In most charts, recurring software and SaaS subscriptions sit in operating expenses, commonly somewhere in the 6000s, under a name like "Software and subscriptions" or "Dues and subscriptions." There is no universal number, so the answer for your company is whatever your chart of accounts calls it.
The distinction that actually matters is not the number, it is capitalize versus expense. A monthly subscription is an operating expense. Internally developed software, or a perpetual license with a multi-year useful life, may need to be capitalized and amortized instead, which is an asset account in the 1000s. That is a call for your accountant, not for a coding rule, and it is one of the few places where a coding mistake genuinely distorts the financial statements rather than just the category detail. If your software spend is scattered across dozens of cards and you cannot see it in one place to begin with, that is a IT spend management problem before it is a coding problem.
What is the difference between a GL code and a GL class code?
These are unrelated things with confusingly similar names, and searching for one reliably turns up the other.
A GL code, as described above, is an accounting term: an account in your chart of accounts. A GL class code is an insurance term. It is a classification number used by general liability insurers to categorize your business by the kind of work you do, which drives your premium. If you are looking at a four-digit number in a policy document, that is a class code, and your bookkeeping software has no use for it. If you are looking at a number in your accounting system, that is a GL account code, and your insurance broker has no use for it.
How do you automate GL coding?
Automating coding works because coding is far more repetitive than it feels while you are doing it. The same vendors bill you every month and land in the same accounts. Once a system has seen your posting history and your chart of accounts, most of the decision is pattern matching rather than judgment.
A practical setup does four things:
- Reads the document, including line items. Vendor-level coding is not enough when one supplier bills you for several different things.
- Codes into your real chart of accounts. Not into a generic category list you then have to map, which just moves the manual work somewhere less visible.
- Applies your dimensions. Department from the cardholder or submitter, class and location from the ledger, project from a rule you set once.
- Flags what it does not know. A new vendor or an unfamiliar line item should be routed to a person. A confidently wrong code that nobody reviews is more expensive than a blank field, because nobody goes looking for it.
That last point is the one to press vendors on. Almost every product in this category will quote you an automation percentage. The more useful question is what happens to the remainder, and whether you can see which lines were assigned by rule, which were learned from history, and which a human confirmed. Invoice coding software that shows its work is auditable. One that returns a finished-looking coded invoice with no provenance is not.
Historic data is worth cleaning up before you automate, because the system learns from it. If your card and bank history lives in exports rather than in your ledger, get it in first: pull the statements, and where your bank only gives you a spreadsheet you can convert that CSV into a QBO file QuickBooks will import rather than keying a year of transactions by hand. Coding automation trained on a clean, complete history is materially better than one trained on six months of partial data.
Common GL coding mistakes
Coding at the vendor level. Amazon, Google and most large suppliers sell you several different categories of thing. One default account per vendor guarantees a share of miscoded lines that nobody ever catches.
Letting the chart of accounts sprawl. Every time someone cannot find the right account they create a new one. Charts drift from 60 accounts to 300, coding gets slower and less consistent, and year-over-year comparisons break. Prune it annually.
Using the memo field as a coding system. If the real information about what an expense was lives in free text, it is not in your reporting. It is in a note.
Coding to the payment instead of the expense. The account is determined by what you bought, not by which card or account it was paid from. This one shows up constantly in company card spend, and it is a large part of why card reconciliation gets a reputation for being painful.
Deferring the whole month to close week. Coding a month of invoices in two days, with the least context and the most time pressure, is when the largest errors get made. Code continuously as documents arrive.
Where to start
If coding is currently a bottleneck, do this in order. Export your chart of accounts and read it. Cut the accounts nobody uses. Write down the ten vendor-to-account mappings that cover the most volume, because in most companies ten rules cover the majority of lines. Then automate the repetitive part and keep a person on the exceptions.
Expenditure reads each invoice and receipt, assigns the GL account and your other ledger dimensions from your own connected chart of accounts, flags what it is unsure about, and syncs the coded record to QuickBooks, Xero or NetSuite. It works with the cards and banks you already have and never moves or holds your money. If you want the wider workflow rather than the coding step alone, see accounts payable automation, and for the underlying category rules see our guide on how to categorize business expenses.
This article is general information about accounting practice, not accounting or tax advice. Your controller or CPA owns your chart of accounts and your treatment decisions.