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 thirteen minutes you will know which single field puts every document’s receivable or payable line where it goes, why that field is almost never wrong on purpose and quite often wrong by history, 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. Across all ninety tenant databases there are about one hundred and seventy records in twenty-six tenants sitting in exactly that state. The control in the same count is fifty-four thousand suppliers on some other type, in sixty-eight tenants, so that number is small because it is rare, not because nobody looked.

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. If the value resolves to a code the posting company has no mapping row for, finalising refuses with an error naming that code — loud, immediate, and company-wide rather than about this one customer. The quieter failure is a blank. When the effective value comes back empty, the posting service simply does not add the receivable or payable line, and nothing says so. About thirty-four thousand records across eighty tenants carry no type at all, and fifteen thousand documents in twelve tenants name one of them — against twelve million documents in seventy-four tenants whose entity has one.

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, and there will not be many — the platform-wide count was two hundred and sixty. 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