SAP Purchase Order Account Assignment Table: EKKN Explained

The Short Answer: It's EKKN

If you've been digging through SAP looking for where account assignment data lives on a purchase order, the table you want is EKKN - Account Assignment in Purchasing Document. That's the primary database table SAP uses to store all account assignment details attached to a PO line item. Not EKKO. Not EKPO. EKKN.

Most people new to SAP MM stumble here because the account assignment category field (KNTTP) does show up in EKPO, but the actual assignment objects - the cost center, the order number, the WBS element, the asset - those live in EKKN. It's a separate table joined back to the PO item level. Once you understand that split, everything else clicks.

The Core SAP PO Table Structure

Before going deep on EKKN, you need the full picture. SAP purchasing data is spread across several related tables that each handle a specific layer of the document:

• EKKO - Purchasing Document Header. This is your PO-level data: vendor, company code, purchasing org, document date, and the document number (EBELN) that ties everything together.
• EKPO - Purchasing Document Item. This stores line item details: material number, quantity, unit price, delivery date, plant, and the account assignment category (KNTTP) field that signals how the item will be accounted for.
• EKKN - Account Assignment in Purchasing Document. This is where the actual account assignment objects are stored: cost center (KOSTL), internal order number (AUFNR), WBS element (PS_POSID), asset number (ANLN1/ANLN2), sales order (KDAUF), and the G/L account (SAKTO).
• EKBE - Purchasing Document History. This logs every transaction against the PO - goods receipts, invoice receipts, cancellations - linked back through EBELN and EBELP.
• EKET - Scheduling Agreement Schedule Lines. Used when a PO has multiple delivery dates spread over time.

The relationship between these tables is straightforward once you see it laid out. EKKO and EKPO share the key field EBELN (the PO number). EKPO and EKKN share both EBELN and EBELP (the item number). EKKN adds a third key field: ZEKKN, which is the sequential number of the account assignment - critical when you have multiple account assignment lines split against a single PO item.

EKKN: Key Fields You Actually Need

When you open EKKN in SE16N, you're going to see a lot of columns. Most of them will be empty depending on what account assignment category is in use. Here are the ones that matter in practice:

• EBELN - Purchase Order Number (links back to EKKO and EKPO)
• EBELP - Item Number of the PO
• ZEKKN - Sequential number of the account assignment line (starts at 1, increments when cost is split)
• KNTTP - Account Assignment Category (K, A, F, P, C, etc.)
• SAKTO - G/L Account number to be charged
• KOSTL - Cost Center (populated when KNTTP = K)
• AUFNR - Internal Order or Production Order number (populated when KNTTP = F)
• PS_POSID - WBS Element for project-based procurement (populated when KNTTP = P)
• ANLN1 / ANLN2 - Asset Main Number and Sub-number (populated when KNTTP = A)
• KDAUF - Sales Order Number (populated when KNTTP = C)
• VBELN - Sales Document reference
• MENGE - Quantity assigned to this account assignment line (relevant in multiple account assignment scenarios)
• PRCTR - Profit Center

The key thing to note: any given EKKN row will only have some of these object fields filled in, depending on the category. A cost center PO (K) fills KOSTL but leaves AUFNR blank. A project PO (P) fills PS_POSID. You don't get all of them at once unless you've done something unusual in configuration.

Account Assignment Categories: What Each One Means

The account assignment category is the control switch that tells SAP two things: which account assignment objects are required, and how the accounting entries should post when a goods receipt or invoice receipt hits the system. Here are the standard categories you'll encounter most often:

• K - Cost Center: The most common category. Used when you're purchasing services or consumables that get expensed directly to a department. Requires a G/L account and cost center. When goods receipt is posted, the material is consumed immediately - it never enters inventory.
• A - Asset: Used for purchasing fixed assets like equipment or machinery. Requires the asset main number (ANLN1) and sub-number (ANLN2). The G/L account is determined automatically by the system from the asset master data.
• F - Order: Used for internal or production orders. Requires the CO/PP order number in the AUFNR field. Costs flow to the internal order for tracking and settlement.
• P - Project: Used in project-based procurement. Requires the WBS element. Common in engineering, construction, and professional services environments.
• C - Sales Order: Ties procurement costs directly to a specific customer sales order. Costs roll up against that deal for profitability analysis in CO-PA.
• U - Unknown: A placeholder category for when account assignment will be finalized later. Useful in theory, creates reconciliation problems in practice. Avoid relying on it.

You configure and customize these categories in transaction OME9, or by navigating SPRO → Materials Management → Purchasing → Account Assignment → Maintain Account Assignment Categories. That's where you control which fields are required, optional, displayed, or hidden for each category.

How to Query EKKN: Practical SQL and SE16N Tips

If you're pulling this data for a report, an audit, or a data migration, you almost always need to join EKKN with EKKO and EKPO. Here's the basic join structure:

For a join in ABAP or custom reports:

• Join EKKO to EKPO on EKKO.EBELN = EKPO.EBELN
• Join EKPO to EKKN on EKPO.EBELN = EKKN.EBELN AND EKPO.EBELP = EKKN.EBELP

That three-table join gives you the PO header context, the line item details, and the full account assignment breakdown in a single result set.

In SE16N: Go to SE16N, enter table EKKN, and filter by EBELN (PO number) or KOSTL (cost center) or AUFNR (order number) depending on what you're looking for. If you're auditing all POs hitting a particular cost center, filter on KOSTL. If you're tracking down what charged to a specific internal order, filter on AUFNR. The ZEKKN field matters when a PO item has been split across multiple cost centers - you'll get multiple rows per EBELP in that case, each with a partial MENGE.

Transaction ME2K is also worth knowing - it lets you pull purchase orders by account assignment category directly from the SAP UI without touching tables manually. Useful for business users and consultants who need a quick view without going to SE16N.

Multiple Account Assignment: When One Line Isn't Enough

Standard procurement is one PO line, one account assignment object. But SAP supports multiple account assignment on a single line - splitting a purchase across two or more cost centers, orders, or WBS elements. This is where ZEKKN earns its keep.

When you split a line item across multiple account objects, EKKN generates one row per assignment, each with a unique ZEKKN value (1, 2, 3...). The MENGE field on each row captures the quantity or value allocated to that object. The sum of all ZEKKN rows for a given EBELP should equal the total item quantity or value on EKPO.

A real example: your IT department and HR department both need office chairs. You create a single PO line for the full quantity, but split the account assignment - 300 units to IT's cost center and 200 units to HR's cost center. EKKN will show two rows for that item, each pointing to a different KOSTL with the corresponding quantity in MENGE.

The copy function in the multiple account assignment screen makes this faster - you don't have to re-enter the same account assignment data repeatedly across different items. SAP also has a repeat account assignment function for scenarios where several items share the same account structure.

The EBKN Connection: Purchase Requisitions

EKKN has a parallel table in the purchase requisition world: EBKN. EBKN stores account assignment data for purchase requisitions (PR), not purchase orders. The relationship mirrors EKKN exactly - EBKN joins to EBAN (the PR header/item table) via BANFN (PR number) and BNFPO (PR item number).

When a purchase order is created with reference to a purchase requisition, the account assignment values transfer from EBKN to EKKN automatically. That's the data lineage: EBKN on the requisition side, EKKN on the PO side. If you're doing a full procurement audit trail - from requisition through PO through goods receipt - you need both tables.

Common EKKN Reporting Mistakes

A few things that trip people up when working with this table:

• Forgetting ZEKKN in the join: If you join EKPO to EKKN on just EBELN + EBELP and the item has multiple account assignments, you'll get row multiplication in your result set. Always check whether multiple account assignment is in use and decide upfront whether you want one row per PO item or one row per assignment.
• Expecting EKPO to have the account objects: EKPO has the account assignment category (KNTTP), but the actual cost center or order number is in EKKN. Don't build reports sourcing only from EKPO and wonder why the cost center field is blank.
• Ignoring ESKN for service entry sheets: If a PO line uses item category D (External Service) and a service entry sheet has been posted, the account assignment actuals shift to table ESKN. EKKN holds the planned assignment; ESKN holds the actual assignment post-entry. Both matter for a complete picture.
• Overusing category U (Unknown): Using Unknown as a default creates period-close reconciliation headaches. Finance will chase down every U-coded PO to reassign costs. Set the real category at time of requisition creation.

Using This Knowledge Outside SAP: Connecting Procurement Data to Sales Pipelines

If you're an SAP consultant or implementation partner, understanding the procurement data model at this level is a differentiator when pitching enterprise clients. The people who get hired for SAP MM projects aren't just the ones who know the transactions - they're the ones who can speak to the underlying table architecture, explain why period-close reports break, and diagnose data migration issues before go-live.

That means your outbound prospecting needs to reflect that depth. If you're reaching out to SAP project managers, procurement directors, or ERP implementation leads, the conversation starter can't be generic. It has to reference the actual pain points: EKKN join problems in custom reports, ESKN vs EKKN confusion during service PO audits, multiple account assignment explosions in FI reconciliation.

Finding those contacts starts with the right data. A B2B lead database lets you filter by job title (SAP Consultant, Procurement Manager, ERP Director), industry (manufacturing, construction, professional services - the heaviest SAP users), company size, and location. That's how you build a list of decision-makers who actually care about what you know.

Once you have the list, the outreach has to match the expertise. Don't pitch vague "SAP consulting services." Open with the specific problem - miscoded account assignment categories, EKKN join issues, period-close reconciliation failures - and offer a concrete fix. For a full breakdown of how to structure that kind of cold email, grab the Cold Email Tracking Sheet - it'll help you organize your sequences, track opens and replies, and know exactly where each SAP prospect is in your pipeline.

And if you're building out your cold email tech stack to support this kind of targeted outreach, the Cold Email Tech Stack guide covers the sequencing tools, email validators, and data sources worth using together.

Quick Reference: EKKN Field Summary

• Table: EKKN
• Full name: Account Assignment in Purchasing Document
• Primary keys: EBELN, EBELP, ZEKKN
• Joins to: EKPO via EBELN + EBELP; EKKO via EBELN
• Related tables: EBKN (PR account assignment), ESKN (service entry account assignment), EKBE (PO history)
• Key transaction for reporting: SE16N (raw table browse), ME2K (PO by account assignment), ME21N/ME23N (create/display PO)
• Configuration transaction: OME9 (maintain account assignment categories)

The bottom line: if someone asks you which table stores account assignment data on a purchase order in SAP, the answer is EKKN - full stop. Everything else in the MM purchasing table ecosystem supports it, but EKKN is where the financial routing of your PO line items actually lives.