Purchase Order History in SAP: Tables, Reports, and Tcodes

Purchase order history in SAP is stored in table EKBE, "History per Purchasing Document". It records the follow-on documents posted against a PO: goods receipts, invoice receipts, subsequent debits and credits, and delivery costs. You view it on the PO History tab at item level in ME23N. A purchase order with no movements posted against it has no EKBE rows at all, which is why the tab is sometimes missing.

Last updated July 2026

The phrase "purchase order history" gets used for two different things in SAP, and mixing them up wastes a lot of time. One is the transactional history: what was received and what was invoiced against the order. That is EKBE. The other is the change history: who edited the price, the quantity, or the delivery date, and when. That lives somewhere else entirely, in the change document tables. This article covers both, plus the reports and transaction codes that get you to each one.

What table stores purchase order history in SAP?

Table EKBE, described in the data dictionary as History per Purchasing Document. Every goods receipt, invoice receipt, subsequent debit, and delivery cost document posted against a purchase order item writes a row here. It is the table behind the PO History tab you see in ME23N, and it is the table almost every custom purchasing report ends up joining to.

The primary key tells you a lot about how the data is shaped:

Notice that the key runs down to the item and the account assignment, not just the order. History is kept per PO line, not per PO. That is the single most common mistake in a first attempt at a purchasing report: joining on EBELN alone and quietly multiplying rows.

The two header and item tables you will join to are EKKO for the PO header and EKPO for the PO items. EKKO gives you the vendor, purchasing organization, document type, and order date. EKPO gives you the material, plant, ordered quantity, and net price. EKBE gives you what actually happened afterward.

What is the tcode for purchase order history in SAP?

There is no dedicated "PO history" transaction. You get to it three ways depending on what you are trying to answer.

ME23N displays a single purchase order. Select an item, then open the PO History tab in the item detail area at the bottom of the screen. This is the right tool when you have one order in front of you and someone is asking what happened to it. ME22N is the same screen in change mode.

ME2N, ME2L, and ME2M are the list reports: by PO number, by vendor, and by material. Run with the selection parameter WE101 and you get open purchase order quantities across many orders at once, which is the report most people actually want when they say they need PO history. There is more on that in our guide to the open purchase order report, including why WE101 and WE103 return different numbers.

MB51 lists material documents. If your question is about goods movements specifically, rather than the PO as a whole, MB51 is a faster route than paging through orders one at a time.

Why is the purchase order history tab missing in ME23N?

In most cases because there is nothing to show. EKBE only holds rows once a movement has been posted against the purchase order. A newly created PO that has had no goods receipt and no invoice receipt has no history, so SAP does not render the tab. Post the first goods receipt and it appears.

The second common cause is configuration on the item itself. If the Goods Receipt indicator is not set on the Delivery tab of the PO item, no goods receipt can be posted against that line, so no GR history will ever accumulate. That is worth checking before anyone opens a ticket, because it is a setup question rather than a bug. Item category also matters: limit and service items follow a different flow from standard stock items and do not build history the same way.

SAP publishes a knowledge base article on this exact symptom, KBA 2813012, "Purchase Order history tab missing in ME23n", which is the right reference to cite if you need to escalate. Check the two causes above first, because they account for most of what gets reported.

How to read the PO History tab line by line

Each row on the tab is one follow-on document. Two fields tell you what kind of document it is, and they are easy to confuse because they overlap.

BEWTP is the PO history category. VGABE is the transaction or event type. Both classify the row; they just use different code sets.

The BELNR field changes meaning depending on the category, which trips people up in reports. When BEWTP is E, BELNR is the material document number from the goods receipt. When BEWTP is Q, BELNR is the invoice document number. Same column, two different document worlds, and no way to tell them apart without also reading BEWTP.

Read down the tab and you are reading the three-way match as it actually happened: ordered quantity from EKPO, received quantity from the E rows, invoiced quantity from the Q rows. Where those three disagree is where your goods received not invoiced balance comes from at month end. The mechanics of the comparison itself are covered in what is a 3-way match.

Purchase order history is not purchase order change history

This is the distinction worth getting right. EKBE answers "what was received and invoiced". It does not answer "who changed the price last Tuesday". Change history is stored as SAP change documents, in CDHDR for the header record of each change and CDPOS for the individual field-level before and after values.

You reach them from the order without writing a query. In ME23N, use Environment > Item Changes for a single line, or Environment > Header Changes for the order as a whole. You get the field that changed, the old value, the new value, the user, and the timestamp. For audit questions, that is the real trail, and it is the one to pull when a supplier disputes a price or a date. Version management, activated in the purchasing configuration under OLME, adds a formal revision layer on top if your organization needs approved versions rather than a raw field log. The full editing path is covered in how to amend a purchase order.

Teams that rebuild this history in a warehouse rather than reading it in SAP tend to hit the same problem one level up: once EKBE, CDPOS, and a few staging tables have been joined and transformed a couple of times, nobody can say which job last wrote a given value. That is a lineage question rather than an SAP question, and it is worth being able to trace each field back to the job that produced it before a finance user asks why two reports disagree.

How do I get purchase order history by material?

Use ME2M, the purchase order list by material. It takes a material number and a plant and returns the purchase orders carrying that material, with the same selection parameters as ME2N, so WE101 still gives you open quantities. For a pure movement view, MB51 filtered on material and movement type is quicker.

If you are going to the tables instead, the path runs EKPO by MATNR to get the relevant PO items, then EKBE on EBELN and EBELP for the history of each. Going straight at EKBE by material does not work, because EKBE does not carry the material number.

Where purchase order history lives in other systems

SAP Business One is a different product with a different schema. Purchase orders live in OPOR for headers and POR1 for lines, and the follow-on documents are linked through the base and target document fields rather than through an EKBE-style history table. If someone hands you an S/4HANA table list and you are working in Business One, none of it will apply.

Microsoft Dynamics 365 Business Central moves purchase order lines to posted documents once they are received or invoiced, so the "history" is the set of posted receipt and posted invoice documents rather than a history tab on the live order. Once an order is fully received and invoiced it leaves the open list entirely, which is a genuine reporting gap if you need to see received versus invoiced afterward.

Oracle Fusion Cloud Procurement exposes the same information through the Procurement Purchasing Real Time subject area in OTBI, where you build the received and invoiced comparison as an analysis rather than reading it off a tab.

Getting purchase order history out of SAP and into Excel

Most ME2N and ME2L output can be exported to a spreadsheet straight from the ALV grid, which covers ad hoc analysis. For anything repeatable, the usual options are a query over EKKO, EKPO, and EKBE built in SQVI or SQ01, a CDS view if you are on S/4HANA, or an OData service consumed by whatever reporting layer you already run. Pick based on who maintains it afterward, not on which is fastest to build.

One practical warning: EKBE grows quickly on high-volume purchasing, and unrestricted selects against it in production are a reliable way to get a call from Basis. Filter on EBELN ranges, document date, or plant.

The gap that PO history cannot fill

Everything above assumes the purchase order is already in SAP. Plenty of orders are not. If you sell to customers who send purchase orders as PDF attachments or scans, or you are migrating orders in from a legacy purchasing system, there is no history to read yet because there is no document in the system. Somebody has to key the header and every line first, and that is where the hours actually go.

That is the step our tool handles. PurchaseOrders reads a PO PDF, scan, or photo and returns the header fields and the complete line-item table as Excel, CSV, or JSON, which you then load through your normal import path. To be clear about the boundary: it does not connect to SAP, does not write to EKKO, EKPO, or EKBE, and does not post goods receipts or invoices. It removes the typing in front of the load. The SAP-specific version of that path, including which columns map where, is on our purchase order to SAP page. If you are new to the document itself, how to read a purchase order walks through the fields, and purchase order fields lists what a complete order should carry.

Frequently asked questions

What is EKBE in SAP?

EKBE is the SAP table named History per Purchasing Document. It stores one row per follow-on document posted against a purchase order item, including goods receipts, invoice receipts, subsequent debits and credits, and delivery costs. It is the data source behind the PO History tab in ME23N, and it holds rows only after a movement has actually been posted.

How do I see the purchase order history in SAP?

Open the order in ME23N, select the item you care about, and open the PO History tab in the item detail area. Each row is one goods receipt or invoice receipt with its document number, posting date, quantity, and value. For many orders at once, run ME2N, ME2L, or ME2M instead of opening them individually.

What is the difference between EKBE and CDPOS?

EKBE records transactions against the order, meaning what was received and what was invoiced. CDPOS records changes to the order itself, meaning which field a user edited and what the old and new values were. Audit questions about who changed a price go to CDHDR and CDPOS, not EKBE.

Why does my purchase order have no history?

Almost always because no goods receipt or invoice receipt has been posted against it yet, so no EKBE rows exist. The other common cause is that the Goods Receipt indicator is not set on the Delivery tab of the item, which prevents a GR from ever posting against that line. Service and limit items also behave differently from standard items.

Can you delete purchase order history in SAP?

Not directly, and you should not try. EKBE rows are created by posted material and invoice documents, so the way to correct them is to reverse the underlying document, for example cancelling a goods receipt with MBST or reversing an invoice in MR8M. The reversal writes its own history row rather than erasing the original, which is exactly what an auditor expects to see.

Which table has the purchase order change history?

CDHDR and CDPOS. CDHDR holds one record per change event with the user, date, time, and transaction, and CDPOS holds the field-level detail with the old and new values. Filter on object class EINKBELEG and the PO number in the object ID to isolate a single order.