KB21N — Enter Direct Activity Allocation

KB21N records a direct activity allocation: a sender cost center delivers a quantity of an activity type (machine hours, setup hours, consulting hours) to a receiver, which can be another cost center, an internal order, a WBS element, or a similar CO object. The posting has two components on every line: the quantity entered by the user, and the value, which the system derives by multiplying that quantity by the activity price for the sender cost center and activity type combination. The one structural fact that explains most confusion: this is a pure Controlling posting. No FI document is generated, no vendor or customer is involved, and the amount that lands on the receiver depends entirely on a price that lives outside the transaction, in cost center/activity type planning. If that price is zero, wrong, or not yet calculated, the quantity still posts but the value does not reflect reality.

KB21N is reached for when an activity was actually delivered but was not captured through an automated source such as a production order confirmation, a service confirmation, or a time sheet entry that feeds activity allocation automatically. Typical cases: a maintenance cost center provided hours to a production cost center outside of any order, an internal IT cost center delivered support hours to a project, or a correction is needed because an automatic allocation used the wrong activity type or receiver. It is not used for moving already-posted costs between objects (that is KB11N), and it is not used where the volume of allocations justifies a periodic, rule-based method such as assessment or distribution cycles run at period close. Those cycles replace manual KB21N entry once the allocation logic is stable and repeatable.

Start from the CO document number and pull COBK to confirm it exists with the expected date and period. Use COEP filtered on that document number to see both the sender line (negative or debit) and receiver line (credit), checking the activity type, quantity, and value fields; a nonzero quantity with a zero value confirms a missing or zero activity price at posting time. Cross-check the price by looking at the planned price for that cost center and activity type for the same period, and compare it against what was actually used on the COEP line.

On S/4HANA the underlying transaction and its logic are unchanged; the difference is that actual activity allocation line items also update the universal journal table alongside the classic CO tables, which are retained as compatibility views. A Fiori app exists for posting direct activity allocation as part of the Controlling work center, giving the same fields in a browser-based layout, but the classic transaction remains fully usable and is still the faster path for high-volume manual correction work.

This is a Controlling functional problem, owned by the CO or FI/CO consultant responsible for cost center accounting, not Basis and not ABAP unless a custom validation or substitution is involved. A good handover includes the CO document number, the sender and receiver objects, the activity type, and whether the price used was plan or actual, so the receiving consultant does not have to re-derive the valuation from scratch.

KB11N is the closest sibling, used for reposting costs rather than activity quantities, and is worth comparing directly to understand which transaction applies to a given correction. KP06 is where the plan price that values a KB21N posting is maintained, and is the first stop when a posting comes through at zero value. KSB1 and KOB1 are the reporting transactions used to confirm that an allocation actually reached the intended cost center or order with the expected value. OKB9 is relevant when the question is why an automatic allocation posted differently than a manual one would have, since it governs default account assignment logic for automatic postings.