KO01 — Create Internal Order Master Record
KO01 creates a CO internal order master record used to plan and collect costs, and sometimes revenue, for a defined job such as a marketing campaign, minor project, or overhead task. The order's behavior, including whether it is statistical or real, what it can be settled to, and what statuses it passes through, is almost entirely governed by the order type entered on the initial screen, not by anything filled in later.
This page covers the internal order creation transaction KO01 in Controlling, focusing on how the order type template drives almost every downstream problem consultants see with orders. It walks through the real creation sequence, the master data tables the save touches, and a diagnostic breakdown of the failure categories that actually show up in support tickets, from blocked postings due to status to missing settlement rules.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,243 words
What it does
KO01 creates a new internal order in Controlling, a CO object that collects planned and actual costs, and in some configurations revenue, against a specific job or activity that does not justify a full WBS structure. The structural fact that explains most confusion: the order type entered on the initial screen is a template that fixes the number range, the field selection layout, the settlement profile, the budget profile, and the status profile before the user enters a single other field. Whether the order behaves as a real cost collector that can be settled elsewhere, or as a statistical order that only mirrors postings for informational reporting, is also decided at the order type level. Master data errors reported against a specific order are frequently actually configuration errors on the order type used to create it.
When it is used
KO01 is reached for at the start of any cost-tracking activity that is short-lived or doesn't warrant a project structure: a marketing event, an internal repair or maintenance job, a small capital item, an R&D task, or an internal service being billed out. It sits before any FI or MM posting can reference the order as a CO account assignment object. Consultants use it interactively for one-off orders during testing or business requests; for volume creation, mass loads go through the order BAPI or LSMW rather than the transaction. On S/4HANA, functionally equivalent Fiori apps exist for order creation, but KO01 remains the fastest way to check whether an order type is configured correctly, since the screen exposes every profile assignment directly.
How to use it
- Enter the order type first on the initial screen; this determines every field, profile and number range that follows, so confirm it before accepting any default.
- Confirm controlling area and company code if the system does not default them correctly.
- Enter a short description and press enter to reach the master data screen.
- Populate responsible cost center, business area and functional area as required by the order type's field selection.
- Set validity dates if the order type uses them.
- Check the Control tab for the statistical indicator and confirm a settlement profile is present if the order is meant to be settled later.
- Assign a budget profile if budgeting is expected and the order type does not default one.
- Save; the system assigns the order number from the order type's number range, or prompts for an external number.
- Release the order via a status change if the order type's status profile blocks postings in the created status, since many order types default to a created-only status.
Key fields
- AUFK - order master header: order number, order type, controlling area, company code, responsible cost center, object class, statistical indicator, object number (OBJNR).
- JEST - system and user status records keyed on the order's object number, showing current and historical statuses such as created or released.
- COBRA - settlement rule header for the order, holding the settlement profile and allocation structure reference.
- COBRB - settlement rule distribution lines, listing the receivers (cost center, GL account, WBS element) and their percentages or amounts.
How to prove it in the data
In SE16, pull AUFK filtered on controlling area and order type to confirm the order exists with the expected statistical indicator and object class, and note its OBJNR. Then query JEST where OBJNR equals that value and INACT is blank, to see the currently active status codes rather than the full history. To confirm a settlement rule exists, check COBRA and COBRB for that order number; an order with actual postings but no COBRB rows will never settle.
ECC vs S/4HANA
KO01 continues to work on S/4HANA without functional change. AUFK, JEST, COBRA and COBRB remain the master data tables; the merge of actual and planning line item tables into the universal journal affects reporting tables, not order master data creation. A Fiori app for managing or creating internal orders exists as the modern equivalent, but the transaction is still widely used because it exposes profile assignments directly on one screen.
Common pitfalls
- Status blocking postings: the order sits in a created-only status and rejects actual documents with a status error. Check JEST for the active status against the order's status profile before touching config; the fix is releasing the order in KO02, not changing the profile.
- Order type misconfigured for settlement: settlement profile or allocation structure missing or wrong on the order type, which surfaces later as a settlement error rather than at creation time. Diagnose against the order type, since every order created from it inherits the same gap.
- Missing settlement rule: the order accumulates real costs but nobody maintained a settlement rule in COBRA/COBRB, so period-end settlement leaves costs stuck on the order. Symptom looks like a reporting problem but is a master data gap on that specific order.
- Statistical versus real confusion: the order was created as statistical only, so it cannot be settled and actual real costs are landing elsewhere in parallel, usually the cost center. Reconciliation looks wrong because two objects are both holding a version of the same cost. Check the statistical indicator and object class on AUFK first.
- Cross controlling area mismatch: the order is created in the wrong controlling area relative to the posting document's controlling area, producing a cross-CO-area rejection. This is a master data error, not a posting error, and reposting will not fix it.
- Number range exhaustion: KO01 fails outright with a number range message; this is a number range configuration issue for that order type, not something fixable on the order screen.
- Fields appear missing: the order type's field selection variant hides fields the business expects to enter, which looks like missing data but is a configuration display issue, confirmed by comparing field selection settings across order types.
Whose problem this is
This is functional CO territory: order type configuration, status profiles, settlement profiles and field selection are owned by the CO consultant. Basis involvement is limited to number range maintenance. ABAP is only pulled in if a custom validation or enhancement blocks the save. A good handover states the order type, controlling area, the exact error text, the tab where the issue occurs, and whether one order or every order of that type is affected.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/ko01ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.