ME9F, NACE, NAST: SAP Purchase Order Output Determination

Purchase order output in SAP is driven by three objects: ME9F processes the messages, NACE configures the output type (NEU under application EF), and the NAST table records what was created, how it was meant to leave the system, and whether it worked. If a vendor says the order never arrived, NAST is the first place to look, because it holds a row per message with a processing status and a transmission medium.

This is a reference for the SAP MM side of purchasing output. It covers the tables and transaction codes, the fields that actually decide whether a PO prints or emails, the usual reasons output silently does nothing, and the one change in S/4HANA that invalidates a lot of older advice.

Last updated August 2026.

What table stores purchase order output messages in SAP?

NAST, the message status table. Every output SAP proposes or creates for a purchasing document writes one NAST row. The row records the application, the document it belongs to, the output type, who it goes to, how it should be transmitted, when it should be dispatched, and whether processing succeeded. For purchase orders the application key is EF and the object key is the PO number.

KAPPL, OBJKY, KSCHL, SPRAS, PARNR and PARVW together identify a message. That combination is why the same purchase order can carry several NAST rows at once: one printed copy to the buyer, one external send to the vendor, one EDI message, each a separate row with its own status.

A quick look at what a document actually produced:

SELECT objky, kschl, parvw, parnr, nacha, vsztp, vstat, erdat, eruhr
  FROM nast
 WHERE kappl = 'EF'
   AND objky = '4500001234'
 ORDER BY erdat, eruhr.

If that query returns nothing, output determination never found a condition record. That is a different problem from output that was found and then failed, and the fix is in a different place.

What is the tcode for purchase order message output in SAP?

ME9F is the transaction for processing purchase order output. NACE is where output types and their processing routines are configured, and MN04 through MN06 maintain the condition records that decide when an output is proposed. The split matters: NACE and MN04 control whether a message is created, ME9F controls whether a created message is actually sent.

Inside ME21N, ME22N and ME23N the Messages screen is the per document view of NAST. It shows the output type, medium, partner and status for that one order, which is usually faster than a table query when you are chasing a single complaint.

SAP purchase order output type NEU and application EF

SAP groups output configuration by application. Purchasing documents use application EF, and the delivered output type for a purchase order is NEU. Everything else hangs off that pair: the output procedure assigned to the document type, the access sequence that decides which condition tables are checked, the condition records themselves, and the form and program that produce the printed or emailed result.

The chain runs in this order, and a break anywhere in it produces the same visible symptom of nothing happening:

1. The purchase order document type has an output determination procedure assigned.
2. The procedure contains the output type, NEU in the standard system.
3. The output type has an access sequence pointing at one or more condition tables.
4. A condition record exists in one of those tables that matches this document.
5. The condition record names a partner function, transmission medium and dispatch time.
6. The output type has a processing routine, meaning the program and the form to run.

Steps one to three are configuration and rarely change after go live. Steps four and five are master data that buyers and functional teams change constantly, which is why almost every live output problem turns out to be a missing or wrong condition record rather than broken customizing.

How to configure a purchase order output type in NACE

Open NACE, select application EF, then choose the object you need. Output Types lists NEU and any custom types. Selecting a type exposes the general data, the default values that seed a new condition record, and the processing routines that bind the type to a program and a form.

Two settings inside the output type cause more confusion than the rest combined. The first is the default dispatch time, because it decides whether saving the PO sends anything at all. The second is the access sequence, because an output type with no access sequence can only ever be added manually to a document. Neither produces an error message when it is wrong. The output simply does not appear.

Condition records themselves are maintained in MN04, not in NACE. This trips up people who correctly configure an output type, see nothing happen on a new PO, and go back to NACE looking for the mistake. The configuration was fine. There was no condition record telling SAP that this vendor or this document type should receive that output.

How to process PO output in SAP with ME9F

ME9F selects existing NAST rows and processes them. Run it with the purchasing document number, the vendor or the document type, and it lists the messages that match. The processing status field on the selection screen is the one that matters: restrict it to status 0 to find output that was created but never sent, or status 1 to find and resend something that already went out.

Selecting a row and choosing Output Message runs the processing routine for that message. The Processing Log on the same screen is the single most useful diagnostic in the whole area, because it carries the actual error text. A message sitting at status 2 with a log entry about a missing output device is a printer assignment problem. The same status with a log entry about an invalid email address is a vendor master problem. Without reading the log, both look identical from the NAST row.

Output set to dispatch with a scheduled job never leaves the system on its own if that job is not running. Rows accumulate at VSTAT 0 and nobody notices until a vendor calls, because SAP raises no alert for output that was created and simply never processed. Any background job whose only job is to push documents outward is worth an independent check that it is still running, since the failure mode here is silence rather than an error.

The transmission medium decides how the purchase order leaves SAP

NACHA on the NAST row holds the transmission medium. It is set from the condition record, and it determines which processing path SAP takes. Changing it after the message has been created does not re-run determination, it only changes what happens on the next processing attempt.

Medium 5 and medium 7 are the pair people confuse. External send with a communication strategy is what actually emails a PDF to an outside vendor. Simple mail sends an internal SAP mail. Setting a vendor output to 7 produces a message that processes successfully, reports status 1, and never reaches the vendor.

Medium 6 leaves through the EDI path and produces an outbound purchase order IDoc rather than a printable document, which is a different troubleshooting exercise entirely.

Why is my SAP purchase order not printing?

Work down the chain in the order SAP does. In practice one of the first four causes below accounts for nearly every case, and all four are visible from ME23N and MN06 without needing a developer.

The VSTAT values are worth memorizing because they read backwards from what people expect. Status 1 means SAP considers the job done, not that the vendor received anything.

To sweep for output that quietly stalled across all purchase orders:

SELECT objky, kschl, parnr, nacha, vsztp, erdat
  FROM nast
 WHERE kappl = 'EF'
   AND vstat = '0'
   AND erdat < @cutoff_date
 ORDER BY erdat.

SAP purchase order print preview not working

Print preview runs the processing routine without dispatching, so a preview that fails is telling you the form or the program is the problem, not the condition record. If the message list in ME23N shows the output but preview returns nothing, check the processing routine assigned to the output type in NACE first.

Preview also behaves differently by medium. An output configured for external send may not preview the same way a print output does, because the two take different processing paths. Testing a change by previewing a print output and then switching the live condition record to external send is a common way to ship a change that was never actually tested.

S/4HANA replaced this for purchase orders, and older guides do not say so

SAP S/4HANA introduced a new output management framework that determines output parameters through the Business Rule Framework plus (BRF+) and Output Parameter Determination rather than through the classic condition technique in NACE and NAST. For purchase orders this is the direction SAP has taken, and it changes where you look when something goes wrong.

The practical position, and the reason two engineers can both be right in the same argument:

• S/4HANA Cloud always uses the new output control. Switching back to the NAST logic is not possible there.
• S/4HANA on premise keeps message determination as the default, with the new output management inactive unless it is switched on.
• ECC uses NACE and NAST only.

So on an on premise S/4HANA system that was upgraded from ECC, everything in this article still applies, and the NAST rows are still there. On a cloud system, NACE is not the answer and searching for the NAST row will waste an afternoon. Establish which framework your system uses before you troubleshoot, because the symptom looks the same either way.

The other side: purchase orders arriving from someone else’s SAP system

Everything above is about output, meaning documents leaving your system. The mirror image is the problem most suppliers have. A customer running SAP emails a PDF purchase order produced by exactly this mechanism, and somebody at the receiving end retypes the header and every line into their own order entry.

That is the gap PurchaseOrders fills. It reads a purchase order PDF, scan or photo and returns the order number, vendor, dates, item codes, quantities and prices as CSV, Excel, JSON or API output. It does not connect to SAP, does not create purchase orders, does not run ME9F, and does not write to NAST, EKKO or EKPO. It turns a document into columns, and the load into your own system stays yours to run.

If you are loading purchase order data into SAP rather than reading it out, the SAP purchase order import page covers the routes that do write documents, and BAPI_PO_CREATE1 is the function module behind most of them. Teams on other systems follow the same pattern with a different loader, such as the NetSuite purchase order import and its CSV Import Assistant.

Frequently asked questions

What is the difference between NACE and ME9F?

NACE configures output: the output types, procedures, access sequences and the programs and forms that produce a document. ME9F processes output that already exists, letting you print, resend and read the processing log for individual messages. NACE decides whether a message is created, ME9F decides whether a created message is sent.

What is output type NEU in SAP?

NEU is the standard output type delivered for purchase orders under application EF. It is the message SAP proposes when a PO is created, and it carries the default transmission medium, partner function and dispatch time that seed a new condition record. Most systems either use NEU directly or copy it into a custom output type.

Which table holds SAP output condition records?

Condition records for output live in condition tables named with a B prefix under the messages application, and the access sequence on the output type decides which of them are read and in what order. NAST is a different thing: it stores the messages actually created for documents, not the rules that create them.

What does VSTAT 1 mean if the vendor never got the purchase order?

It means SAP successfully handed the message to its processing routine, not that the vendor received it. For external send, status 1 says the mail was passed to SAPconnect. Delivery after that point is tracked in the send queue and the mail system, not in NAST.

How do I resend a purchase order to a vendor in SAP?

Run ME9F, select the purchase order and set the processing status to 1 to list messages already sent, then select the message and choose Output Message to process it again. If no message exists to resend, add one on the Messages screen in ME22N, which creates a fresh NAST row you can then process.

Why is the transmission medium missing on my PO output?

The medium comes from the condition record, so a blank value usually means the record was created without one or the output was added manually on the document without completing the communication details. Check the record in MN06 and the message details on the PO before changing configuration.

Does S/4HANA still use NAST for purchase orders?

On premise S/4HANA keeps message determination and NAST as the default, with the newer BRF+ based output control inactive unless it is switched on. S/4HANA Cloud always uses the new output control and cannot fall back to NAST. Check which framework is active before troubleshooting.

Can PurchaseOrders send purchase orders out of SAP?

No. PurchaseOrders reads purchase order documents and returns structured data as CSV, Excel, JSON or API output. It does not connect to SAP, does not trigger output, and does not create or transmit documents. It is used on the receiving side, where a PO arrives as a PDF and the data has to become columns.

Related reading

• SAP purchase order tables EKKO and EKPO, the header and item tables behind every PO.
• SAP purchase order status tables, for reading where an order stands.
• Purchase order history in SAP and the EKBE table.
• Purchase order IDoc, for output that leaves through EDI.
• BAPI_PO_CREATE1, the function module that creates purchase orders.
• Purchase order import into SAP, for loading PO data in.