Independent IFS Cloud practice · Finance and supply chain design
Goods move correctly and are booked wrongly: agree posting control before go-live
IFS Cloud posting control is the set of rules that turns a business event, such as a goods receipt or a delivery, into a financial transaction with accounts and code parts. It sits between operations and finance, and it belongs to both functions, so neither designs it alone. The gap shows up at month-end as an inventory value that does not tie to the ledger and as variances nobody owns, and the argument that follows starts at the ledger and ends on the shop floor.
This article describes system behaviour as the IFS Cloud documentation presents it. It gives no accounting advice. Which accounts a transaction hits is a decision for your finance function and your auditors.
Key takeaways
- A supply chain event becomes a financial transaction through a posting type, and control types supply the data that decides each code part of the account string.
- Posting control rules are a finance decision with an operations input. Finance owns the accounts, and operations owns the events that trigger them.
- IFS documents standard posting types for supply chain; the design session uses that list and does not invent codes.
- The test is to trace one transaction per event from the stock record to the ledger entry, with a named person on each side.
- The deliverable of the design session is a table: event, expected entry, owner and test evidence.
1.What is posting control in IFS Cloud, and why do operations care?
Posting control in IFS Cloud decides which accounting entries a business event creates. When a warehouse operator receives goods against a purchase order, issues material to a shop order or delivers against a customer order, the system creates a financial transaction through a posting type and its control types. The IFS documentation on posting control for supply chain and manufacturing lists the posting types used for these events.
Operations cares because the operator’s transaction is the trigger. A receipt booked against the wrong order, a delivery confirmed late or an adjustment entered for convenience each produce a ledger entry, whether or not the operator knows it. A warehouse team that understands which events post, and why, makes fewer corrections. The warehouse side of the same question, the location and transaction design that feeds these rules, is covered in warehouse structure design in IFS Cloud.
2.Posting types, control types and code parts: how do the pieces fit?
A posting type describes the debit and credit postings for one kind of event, and a control type supplies the data that decides the value of a code part in the account string. The documentation on posting types and system events describes how these are defined.
| Piece | Role |
|---|---|
| System event | The business event that triggers a posting, for example a receipt or a delivery |
| Posting type | The debit and credit postings created for that event |
| Control type | The data, such as a part, a site or a supplier attribute, that decides the value of a code part |
| Code part | One element of the account string, for example account or cost centre |
Each posting rule therefore answers one question: for this event, and for this kind of part or order, which value goes into each code part? Operations supplies the facts that the control types read, such as a part attribute. Finance supplies the accounts. If either side changes its data without telling the other, the postings change silently.
3.Where does preposting come in?
Preposting lets a user assign accounting values to a document line, for example on a purchase order or a purchase requisition, before the transaction posts. The IFS documentation has separate pages on entering preposting on a purchase order and on a purchase requisition.
The design question for the session is which documents use preposting and who may enter it. A buyer who enters account values on a requisition is making an accounting decision, so finance should know that this happens. Where it does not happen, the posting rules from section 2 carry the full load. Write the answer for each document type in the session record and do not leave it to habit.
4.Which supply chain events should finance and operations walk through together?
Finance and operations should walk through every supply chain event that moves stock or value, one event at a time, with the standard posting types from the IFS documentation in front of them. Do not invent codes. Take the posting type from the documentation page and confirm it in your own environment.
| Event | What operations records | What finance must confirm |
|---|---|---|
| Receipt against a purchase order | Quantity, part and location at goods receipt | The entry created at receipt and its link to the later supplier invoice |
| Issue to a shop order | Material issued to the order | The entry that moves value from stock to the order |
| Delivery against a customer order | Quantity delivered and delivery date | The entry created at delivery and its link to the later customer invoice |
| Transfer between locations or sites | From and to location, quantity | Whether the move creates an entry at all, and in which company |
| Adjustment after a count | Counted quantity and reason | The account that carries the difference |
Costing is a separate subject. How a part is valued is described in inventory valuation methods and cost levels in IFS Cloud, and the gap between a delivery and its invoice is covered in delivered but not invoiced.
5.How do you test posting control before go-live?
Test posting control by following one transaction per event from the stock record to the ledger entry. Each side has a named owner: the operator or key user who made the transaction, and the finance person who reads the entry.
- Choose one transaction per event from the table in section 4, using a real part and a real order.
- Record the expectation first. Finance writes down the accounts it expects before the transaction is made.
- Make the transaction in the test environment and note its reference.
- Compare. The entry in the ledger is set against the expectation, and every difference becomes a defect with an owner.
The method for planning and tracking such tests is covered in testing in IFS Cloud, and the UAT test tracker template lists posting control as a test item. This article does not repeat that method.
6.What goes wrong when nobody owns the design?
When nobody owns posting control, two things happen at the first close. The inventory value in the stock module does not tie to the ledger, and nobody can say which event created the difference. Each side then reconciles from its own end: finance from the ledger, operations from the stock records, and the meeting ends without an owner for the variance.
The result is a recurring monthly discussion instead of a one-time fix. The cure is the table from section 4, kept as a controlled document with a named owner for each row and a review date after the first period-end close. The consequences of a late discovery at close are described in the month-end catch that comes too late.
7.What is the agenda of a posting control design session?
A design session with finance and operations in the room covers six items:
- List the supply chain events in scope, using the IFS documentation of standard posting types.
- For each event, finance states the expected entry in words, with the accounts it intends.
- For each event, operations states what triggers it and who performs it.
- Name one owner on the finance side and one on the operations side for every row.
- Decide where preposting is used, and who may enter it.
- Agree the test evidence: one traced transaction per event, with the reference and the ledger entry attached.
The output is the table with four columns: event, expected entry, owner and test evidence. It goes into the project record next to the other decisions, as described in the IFS Cloud ERP implementation guide.
8.Frequently asked questions
What is posting control in IFS Cloud?
Posting control in IFS Cloud is the set of rules that turns a business event, such as a goods receipt or a customer delivery, into a financial transaction. The rules work through posting types, which define the debit and credit postings, and control types, which supply the data that decides each code part. The accounting decisions in these rules belong to finance.
What is the difference between a posting type and a control type?
A posting type in IFS Cloud describes the debit and credit postings created for one kind of event. A control type supplies the data, such as a part or site attribute, that decides the value of a single code part in the account string.
What is preposting in IFS Cloud?
Preposting in IFS Cloud lets a user assign accounting values to a document line, such as a purchase order line or a purchase requisition line, before the transaction posts. Which documents use preposting, and who may enter it, is a design decision to record in the posting control session, because entering account values is an accounting action.
Who should own posting control, finance or operations?
Finance should own the posting control rules in IFS Cloud, because the rules decide which accounts a transaction hits. Operations owns the events that trigger them and the master data, such as part attributes, that the control types read. Each row of the design table needs one named owner on each side.
How do I check that a stock movement posted to the right accounts?
Follow one stock movement in IFS Cloud from the stock transaction to its ledger entry and compare the entry with what finance wrote down in advance. Do this for one real transaction per event, such as a receipt, an issue, a delivery, a transfer and an adjustment. Every difference between the entry and the expectation is a defect with an owner.
9.About the author
Dariusz Myśliwiec: 18 years hands-on with IFS, including IFS Cloud. Based in Kraków, delivering remotely across Europe and globally through an independent practice. You talk to the consultant who does the work, not a sales layer.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
Does your inventory value tie to the ledger?
If it does not, or nobody can say why, a facilitated design session with finance and operations produces the first version of the event table. A review of your current setup against the documented events works the same way.
Book a posting control session Read about inventory valuation