The other company's copy: what it carries, when it posts, and keeping both books in step — transcript

Play this as a presentation — one slide per step, with the same narration. Every word of every step is on this page.

This presentation is for you if the pairing between your companies is set up and you now answer for both sets of books. In about eight minutes you will know what the buying company’s document says, when it counts, and how to keep the two companies agreeing through corrections and month end.

Step 1 — Read what the purchase invoice copied

After this step you can predict every figure on the buyer’s document. The purchase invoice is built from the sale, line for line. It copies the goods and service lines with their quantities, unit prices, discounts, tax codes and tax amounts, and the sale’s totals, currency, reference and remarks. A payment taken on the sale is not carried. The supplier is GadgetSphere Distribution’s own record, the branch is the receiving branch, and the description begins Auto Created From and ends with the seller’s invoice number. So the price between your two companies is whatever the seller typed. Nothing on the buyer’s side prices it again, which is why the sale must be right before it is finalised: an RM 20,000 sale keyed as RM 2,000 becomes an RM 2,000 purchase in the other company too.

Reference: Organization — What it pairs with in practice

Step 2 — Know when the purchase reaches the buyer’s books

After this step you know which document counts in whose books, and from when. Without Auto Final Target Doc, the purchase invoice arrives as a draft. In GadgetSphere Sdn Bhd you open it, check it against the goods and finalise it. Until then the buyer has no payable and no stock for it, while the seller already shows the receivable. With Auto Final Target Doc ticked, the draft is marked final straight away and handed to the posting, and the checks the Final button runs are not run. So a missing creditor account shows up only afterwards: the posting fails, and the invoice is final with no journal. Ledger And Journal, Error Checking, Missing Journal lists those, and Trace Document, with its Resolve button, repairs one once the account is mapped. A missing purchase or input tax account is worse, because the journal posts short and nothing lists it; the purchase invoice processing guide says how you would notice.

Reference: Purchase Invoice Processing — Step 5: Attach the invoice and finalise

Step 3 — Keep both dates in the same month

After this step the pair will not fall on either side of a month end. The purchase invoice is dated when the pairing runs, not with the sale’s date. In AUTO mode that is the moment the sale is finalised; in MANUAL mode it is the moment you confirm the row. So a sale dated 31 March and finalised on 2 April gives GadgetSphere Sdn Bhd a purchase dated 2 April, and the two companies disagree about March. Finalise intercompany sales on the day they are dated, and confirm MANUAL rows before you close the month. When a draft arrives dated in the wrong month, correct its Transaction Date before finalising, and check the Purchase Invoice applet’s transaction date setting, which can overwrite the date at Final.

Reference: Purchase Invoice (Internal) — Main Details

Step 4 — Work the queue, and find the pairings that failed

After this step you know where to look, so nothing waits unseen. In MANUAL mode each finalised sale leaves one row under Unprocessed in the Intercompany menu: outbound in the Sales Invoice applet, inbound in the Purchase Invoice applet. Nothing clears it by itself. Select the row and press Confirm Intercompany Transaction; the purchase invoice is created then, and the pair moves to Processed. When a pairing fails, in either mode, the reason is recorded, but the row lands in the same Unprocessed list with no error on it, looking like a waiting row. So a row whose Used Config is an AUTO rule is a failure, and the sure check is the buying company’s Purchase Invoice listing: no Auto Created From with that sale’s number, no second document. Find the cause in the set-up steps, but fixing it does not raise the missing document, because nothing re-runs the pairing on its own. Tell whoever keeps the buying company’s books.

Reference: Purchase Invoice (Internal) — Screens and menus

Step 5 — Correct one side without breaking the pair

After this step a correction will not leave the pair half done. Once created, the two are independent: where a void is allowed, voiding the sale touches nothing in the buyer’s books, and the purchase invoice does not block it. Taking the sale back to draft and finalising it again is worse. The sales invoice screen does not offer it, but the programming interface, the API, does, and every finalise runs the pairing afresh and raises a second purchase invoice, because nothing looks for the first. Two Auto Created From invoices for one sale is the sign. So correct each side in its own company, in the same month, and tell the other company’s bookkeeper. Returns pair cleanly, sales return to purchase return. Credit and debit notes do not: the generated purchase credit note raises what the buyer owes, not lowering it, the debit-note pair mirrors that, and both notes’ pages say what to record instead.

Reference: Purchase Credit Note (Internal) — The background jobs behind it

Step 6 — Agree the two companies at month end

After this step you can prove the pair agrees, and you know what the software leaves to you. At each month end, take what GadgetSphere Distribution says GadgetSphere Sdn Bhd owes it, from its Debtor Report, and what GadgetSphere Sdn Bhd says it owes, from its Creditor Report. They should match to the sen. When they do not, look first for drafts not finalised, MANUAL rows not confirmed, a pair dated either side of the month end, and a credit note that went the wrong way. Then remember what a group Set of Books does: it adds the companies’ ledgers together and eliminates nothing, so the sale and the purchase are both in the group total. Agreeing the difference between the two finance teams, and eliminating it, is done outside BigLedger.

Reference: Reviewing a Set of Books Kept in BigLedger — Step 6: Reconcile the group companies with each other

How the steps fit together

    flowchart TD
  s1["Step 1 — Read what the purchase invoice copied"]
  s2["Step 2 — Know when the purchase reaches the buyer's books"]
  s3["Step 3 — Keep both dates in the same month"]
  s4["Step 4 — Work the queue, and find the pairings that failed"]
  s5["Step 5 — Correct one side without breaking the pair"]
  s6["Step 6 — Agree the two companies at month end"]
  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.

Back to the series · Play this as a presentation