The two GL codes on an item, and which one your journal used — transcript
Play this as a presentation — one slide per step, with the same narration. Every word of every step is on this page.
This lesson is for whoever sets up GadgetSphere’s items and then has to answer for the trial balance. An item can carry a general ledger code in two different places, only one of them has a tab, and which one your journal used is not the one most people expect. In about thirteen minutes you will be able to trace any posted line back to the record that decided its account.
Step 1 — Find both places an item can carry an account
After this step you will know what you are actually looking at. The first place is the GL code field on the item’s Main tab: one code, stored on the item itself, visible and editable by anyone who can open the item. The second is a per-company GL code link — a separate row for each combination of item, company and transaction code, so one item can post to a different account in GadgetSphere retail than in the distribution company, and to a different account again on a purchase than on a sale. That second record has no tab anywhere in the applet. The only way to create or change it is the Doc Item With GL Code import template. Twenty-five of the ninety tenants hold these links, forty thousand of them, so they are real and widely used and completely invisible on the screen.
Reference: Doc Item Maintenance — Main tab
Step 2 — Follow the code onto the document line
After this step you will understand why the two records do not behave the way the screens imply. When somebody adds this item to a sales invoice, a purchase invoice or a till line, the applet does not leave the account for later. It reads the item’s Main tab code and writes it onto the document line there and then. From that moment the code belongs to the line, not to the item, and editing the item afterwards will never reach that document again. This is worth holding on to, because almost every surprise in this area comes from it: what posts is what was copied onto the line on the day the document was raised.
Reference: Doc Item Maintenance — Main tab
Step 3 — Read the resolution order, and see which record wins
After this step you can predict the account before you finalise. When the journal is written, a goods-and-services line resolves its account in a fixed order: the code on the line, then the code on the document header, then the per-item-per-company link for that transaction code, then the company default for that transaction code. Because the applet has already put the item’s own code on the line, the item’s own code wins at the first step and the per-company link is never even looked up. At the till the behaviour is slightly different and worth knowing: the item’s own code is used first and the per-company sales link is the fallback when the item’s field is blank. So the relationship between the two records is the reverse of what the screen suggests — the item’s own GL code overrides the per-company link, not the other way round.
Reference: Doc Item Maintenance — Main tab
Step 4 — Explain the invoice that landed in the catch-all account
After this step you will have an answer for the most common complaint in this area. A line that reaches the end of that order with nothing set posts to the company default — the account most charts name simply Sales or Purchases. Nothing warns anybody. The document goes final, the screen returns success, the journal is written, and the only evidence is a general ledger with no detail in it and an account code sitting uselessly on the item. Recurrent complaints in the support record are exactly this shape, sometimes across thousands of items at one customer: the accounts team can see the code on the item, they can see the posting in the catch-all, and there is nothing on either screen connecting the two. The connection is the document line, and it is the thing to look at first.
Reference: Doc Item Maintenance — Main tab
Step 5 — Know why a purchase invoice from a goods receipt ignores the item
After this step you will stop fixing items and expecting invoices to change. When a purchase invoice is built by pulling in a goods receipt or a purchase order rather than by keying items, the line does not consult the item at all. It copies the account from the source document line — whatever was on that line when the earlier document was raised, possibly weeks ago and possibly blank. So you can correct an item’s GL code today, raise an invoice tomorrow against last month’s purchase order, and watch it post to the default again. Nothing is broken. The invoice is faithfully carrying forward what the purchase order said. If a backlog of orders was raised before the coding was right, the accounts have to be put right on those documents, not on the items.
Reference: Doc Item Maintenance — Main tab
Step 6 — Fix the right record
After this step you will spend your effort where it changes something. For documents not yet finalised, put the account on the line — that is the record the journal reads, and it is editable. For documents already posted, the correction belongs on the document or in the journal; changing an item never reaches back. For everything from here on, decide which of the two item records you actually need: the Main tab code if the item posts to the same account in every company, and the per-company link by import if GadgetSphere retail and GadgetSphere Distribution need different accounts for the same product. If you set up the links, remember that the item’s own field will beat them, so leave the Main tab code blank on those items or the links will never be reached.
Reference: Doc Item Maintenance — Troubleshooting
How the steps fit together
flowchart TD
s1["Step 1 — Find both places an item can carry an account"]
s2["Step 2 — Follow the code onto the document line"]
s3["Step 3 — Read the resolution order, and see which record wins"]
s4["Step 4 — Explain the invoice that landed in the catch-all account"]
s5["Step 5 — Know why a purchase invoice from a goods receipt ignores the item"]
s6["Step 6 — Fix the right record"]
s1 --> s2
s2 --> s3
s3 --> s4
s4 --> s5
s5 --> s6
Check yourself
Three to five questions on what you just heard. Every correct answer links to the page that makes it correct, so you can check the source, not just the mark.
Answer key
- Only by the Doc Item With GL Code import — there is no tab for it — Doc Item Maintenance — Import Item
- The Main tab code, because the applet copied it onto the line and the line wins first — Doc Item Maintenance — Main tab
- A line pulled from a goods receipt or purchase order copies the account from that source line, not from the item — Doc Item Maintenance — Main tab
- It posts to the company default for that transaction code, and nothing warns anybody — Doc Item Maintenance — Main tab
- On the document or in the journal — changing the item never reaches a document already raised — Doc Item Maintenance — Troubleshooting
Next: Where the cost on the Costings tab came from · Back to the series · Play this as a presentation