One record, one control account, decided once — 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 at GadgetSphere owns the chart of accounts and has once found a purchase sitting in debtors. In about twelve minutes you will know which single field puts every document’s receivable or payable line where it goes, why that field, when it is wrong, has been made wrong by history rather than by anyone’s choice, and how to find the records it has caught.

Step 1 — Find the field that picks the account

After this step you will know what the AR/AP type on a master record is for. It is not a label. When any document for that entity posts, the platform reads this field, turns it into a transaction code — trade payable becomes CREDITOR, trade receivable becomes DEBTOR, and five more do the same — and then asks the posting company which general ledger account it maps to that code. That account is where the receivable or payable line lands. Nothing on the document itself decides this, and the GL code box on the master record is not it either.

Reference: Supplier — How the AR/AP type reaches a GL code

Step 2 — Learn when the value is chosen

After this step you will know the rule that surprises people. The backend never recalculates this field. It supplies one only when the value it is handed is blank: trade payable if the supplier flag is on, trade receivable otherwise. That runs on create and on every update, but the condition is always the same — only when blank. So the value is set by whichever role the record was first saved with, and it is then permanent until a person changes it. Ticking the supplier flag on a customer a year later does not touch it, because it is no longer blank.

Reference: Customer Maintenance — The AR/AP type is decided once

Step 3 — See what that costs

After this step you will know what the previous step actually does to your ledger. A record created as a customer is stamped trade receivable. Tick supplier on it later and every purchase invoice you raise on it still resolves to the debtor control account — so buying from them credits what they owe you, netting the two sides together, with no contra document and no warning. Nothing reports a record in that state, so the only way to know whether you have one is to look, and step six shows you how.

Reference: Customer Maintenance — The AR/AP type is decided once

Step 4 — Know where it is read from

After this step you will know that this is read live, not frozen. The value is not copied onto the document when the document is created. It is fetched from the master record at the moment of posting, which means correcting the field and reposting moves the account — a genuinely useful property when you find one of these. The query takes the company link’s own type if the posting company has a link row, and the record’s own otherwise. Two sharp edges: it matches on the company alone, and it ends by taking the first row with no ordering at all, so with more than one link row for that company the winner is arbitrary.

Reference: Customer Maintenance — The AR/AP type is decided once

Step 5 — Understand the two ways this fails

After this step you will recognise both failure shapes, and neither stops you finalising. If the value resolves to a code the posting company has no mapping row for, the document still goes final, and the journal posting straight after it fails with an error naming that code: a company-wide problem, not this customer’s. The second shape is a blank. With no value, the posting service builds no receivable or payable line, so the journal cannot balance and the posting refuses it. Nothing lopsided is posted. The document is final with no journal at all, and so is every later one on that record. So after finalising a document for a record you are unsure of, check that its Posting tab shows the journal posted. Trace Document, under Error Checking in the Financial Report applet, reports a missing journal and re-runs the posting once you fix the cause. On a record’s Main tab, look for an empty AR/AP Type.

Reference: Customer Maintenance — The AR/AP type is decided once

Step 6 — Check your own records in two minutes

After this step you will have a check you can run today. Open Entity Maintenance and read down the Entity Ext Type column, which prints the flags joined. Every row reading customer and supplier together is a candidate. Open each one’s Main tab. If the AR/AP type reads trade receivable on a record you genuinely buy from, that is the state this lesson is about, and the fix is one drop-down and a save. Nothing else needs changing: because the value is read at posting time, a reposted document lands on the corrected account.

Reference: Entity Maintenance — Entity listing

How the steps fit together

    flowchart TD
  s1["Step 1 — Find the field that picks the account"]
  s2["Step 2 — Learn when the value is chosen"]
  s3["Step 3 — See what that costs"]
  s4["Step 4 — Know where it is read from"]
  s5["Step 5 — Understand the two ways this fails"]
  s6["Step 6 — Check your own records in two minutes"]
  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.

Next: The Tax tab on a customer is not where tax comes from · Back to the series · Play this as a presentation