Cedar & Co. runs 12 shops from a standing forecast, replenishing stock rather than waiting for a single confirmed export order. Every week, someone raises a replenishment order to Delta Garments, receives goods into a warehouse, moves stock to shops, and eventually pays an invoice. Each of those steps creates a commercial or financial fact: a quantity ordered, a quantity received, a stock balance, an amount invoiced, an amount paid.
These facts belong together in one system, usually the ERP system, because they are commercial and financial by nature — the same category of fact this course separated from technical specifications and task status in the earlier lessons. This lesson shows you where a purchase order, an inventory movement, an invoice and a payment posting should be controlled on a domestic Make to Stock programme, and why letting any of them drift into an uncontrolled spreadsheet creates the same version conflicts this course has already warned against.
You need: the earlier lessons' distinction between what an ERP system, a PLM system and a workflow tool are each meant to control, and the idea that a specification needs one controlled home.
By the end of this lesson you can:
Not covered here: accounting standards, tax rules, or configuring a specific ERP product's finance module. This lesson stays vendor-neutral and focuses on the business rule.
| Term | Meaning |
|---|---|
| Purchase order | A commercial document recording a confirmed quantity, price and delivery expectation for goods being bought. |
| Inventory movement | A recorded change in stock quantity or location, such as a receipt, a transfer or a sale. |
| Invoice | A commercial document recording the amount owed for goods or services delivered. |
| Financial posting | An entry in the accounting records reflecting a commercial event, such as a payment or an accrued liability. |
| Open account | A payment arrangement where the buyer pays the supplier within an agreed period after invoicing, rather than at the time of shipment. |
| Reconciliation | Comparing two records of the same fact, such as a stock count and a system balance, to confirm they agree. |
Every replenishment, receipt, stock transfer, sale, invoice and payment is a commercial or financial event. Course 2's first lesson already established that this category of fact is the ERP system's core job. A Make to Stock programme does not change that rule; it only means the same kind of transaction repeats often, sometimes weekly, rather than once per confirmed export order.
A stock balance, an outstanding invoice amount or a payment due date should always be read from the ERP system's current record. A parallel spreadsheet tracking "what we think is in stock" or "what we think we owe" is exactly the kind of convenience copy that drifts from the system of record over time.
| What can differ | The shapes you will meet | Why it matters |
|---|---|---|
| Export, Make to Order, letter of credit | A single confirmed order, invoiced once near shipment, paid through a letter of credit at the agreed milestone. | Fewer, larger transactions; each one still needs its own controlled purchase order, invoice and payment record. |
| Domestic, Make to Stock, open account | Frequent replenishment orders, invoiced regularly, paid on agreed terms such as 60 days after invoicing. | More frequent transactions increase the risk of an uncontrolled spreadsheet creeping in "to keep track," which is exactly what this lesson warns against. |
| Stock held across multiple shops | Inventory movements include transfers between shops as well as receipts from the supplier and sales to customers. | Every movement is still a commercial fact belonging in the ERP system, whether it is a receipt, a transfer or a sale. |
| An agent or trading company in the commercial chain | A trading company's own purchase order to the factory and its own resale invoice to a retailer are two separate, linked commercial transactions. | Each party's own ERP system controls its own purchase orders and invoices; one company's system is not another company's system of record. |
| Different product families | Socks and hosiery, knit-to-garment, terry towels and home-textiles replenishment orders use the same purchase order, inventory and invoice structure, with different product fields. | The commercial and financial control need is the same across product families; only the product detail on each transaction changes. |
Cedar & Co. runs its 12 shops on a domestic Make to Stock basis, buying from Delta Garments on 60-day open account terms. When a shop manager sees stock running low, a replenishment order is raised in the ERP system, not agreed informally over a phone call. When goods arrive at the warehouse, a goods receipt is recorded in the same system, updating the stock balance. When stock moves to a shop, that movement is recorded too. When Delta Garments issues an invoice, it is matched against the receipt in the ERP system, and the payment due date is tracked from the invoice date under the 60-day term.
A shop manager who instead keeps a personal notebook of "what I think we have" is not creating an alternative system of record; that notebook can drift from the ERP system's balance within days, especially across 12 shops each doing this differently.
The worked numberTwo fixed academy transactions illustrate the scale of a confirmed purchase order, used here only as reference figures, not as Cedar & Co.'s own orders. Order A is 15,000 T-shirts at USD 3.20 per piece. Order B jeans is 3,000 jeans at USD 9.80 per piece.
Whatever the actual size of one of Cedar & Co.'s own replenishment orders, the same principle applies: the confirmed quantity and price on the purchase order are commercial facts controlled in the ERP system, the goods receipt that follows is a separate inventory fact, and the invoice that follows that is a separate financial fact. None of the three should be estimated or reconstructed from a shop manager's memory when the ERP system already holds the confirmed figures.
When a physical stock count in a shop does not match the ERP system's recorded balance, it is tempting to simply trust the physical count and adjust the system to match it. But the disagreement itself is useful information: it may reveal an unrecorded transfer, a receipt entered against the wrong shop, or a sale that was never recorded. Overwriting the system balance without investigating the gap treats the symptom without fixing the underlying entry error, and the same mismatch is likely to recur.
Think of every replenishment, delivery, stock move and invoice as money and goods changing hands, and think of the ERP system as the one ledger that should record every one of those changes. A shop manager's private notebook or a spreadsheet built "to keep an eye on things" cannot replace that ledger; it can only fall out of step with it.
When a stock count does not match what the system says, do not just change the system to agree with the count. Find out why they disagree first, fix the real cause, and then let the system be the answer everyone trusts again.
At one of Cedar & Co.'s shops, a physical stock count shows 40 fewer pieces of a popular T-shirt style than the ERP system's recorded balance. A team member suggests adjusting the system balance down to match the physical count immediately, so the shop's records "look correct" before the next replenishment order is calculated.
What should happen before the system balance is adjusted? Decide before opening the answer.
Investigate the gap between the physical count and the system balance before adjusting anything, since the cause may affect more than this one shop.
1. Check recent stock movements for this style — transfers in or out, receipts, and recorded sales — for any entry that looks missing, duplicated or applied to the wrong shop. 2. Check whether a transfer to or from another shop was received but never recorded, or recorded against the wrong location. 3. Check whether any sales were made without being recorded in the system, such as a manual sale not entered promptly. 4. Only after the cause is identified or ruled out, adjust the system balance to match the verified physical count, and record the reason for the adjustment.
Adjusting the system balance first and investigating later, if at all, risks hiding a real process gap — an unrecorded transfer or sale — that will keep producing the same mismatch at this or another shop.
Order A's and Order B jeans's confirmed values show the scale of a single confirmed commercial transaction:
If a shop's stock balance is silently adjusted without finding the real cause of a 40-piece gap, the next replenishment order calculated from that balance will be wrong in the same direction, and so will the resulting invoice and payment. A recurring, uninvestigated gap across 12 shops can misstate stock and payment obligations by far more than the value of one replenishment order, while the underlying process error — a missed transfer or an unrecorded sale — continues undetected.
Use the T17-C02 Business-system role map workbook. For each commercial or financial fact on a replenishment programme, record which system controls it, how a mismatch should be investigated, and who is responsible for correcting the underlying cause rather than only the number. Start with a replenishment cycle you know, then compare it with Order A and Order B jeans as reference transactions.
[Download the Business-system role map workbook](../../templates/T17-C02-business-system-role-map.xlsx)
1. On Cedar & Co.'s domestic Make to Stock programme, which system should control the current stock balance for a shop?
2. A physical stock count is lower than the ERP system's balance. What should happen first?
3. For Order B jeans, at 3,000 pieces and USD 9.80 per piece, which figure is the confirmed commercial fact that belongs in the ERP system's purchase order record?
| EN | AR | FR | TR | Meaning |
|---|---|---|---|---|
| Purchase order | أمر الشراء (طلبية الشراء) | Bon de commande | Satın alma siparişi | A document from a buyer confirming quantity, price and delivery date, which commits the buyer to pay for the goods it orders. |
| Inventory movement | حركة المخزون | Mouvement de stock | Envanter hareketi | A recorded change in stock quantity or location, such as a receipt, a transfer or a sale. |
| Invoice | الفاتورة | Facture | Fatura | A commercial document recording the amount owed for goods or services delivered. |
| Financial posting | القيد المالي | Écriture comptable | Finansal kayıt | An entry in the accounting records reflecting a commercial event, such as a payment or an accrued liability. |
| Open account | حساب مفتوح | Compte ouvert | Açık hesap | A payment method where the buyer pays the factory an agreed number of days after delivery, with no bank guarantee in between. |
| Reconciliation | التسوية | Rapprochement | Mutabakat | Comparing two records of the same fact, such as a stock count and a system balance, to confirm they agree. |
Next you will learn how a sourcing agent hands off information between a factory's systems and a buyer's systems without creating duplicate entry or conflicting versions. Back to the course map