What happens to SAP output management (NAST) in S/4HANA?

How output worked in ECC, and what S/4HANA changed

In ECC, every printed invoice, emailed order confirmation, and EDI delivery notice went through the condition technique. An output type such as RD00 for billing or BA00 for order confirmation was assigned to a procedure in NACE, condition records in VV11 to VV33 decided who received it and through which medium, a NAST record was written when the document was saved, and a print program such as RVADOR01 or a customer copy of it read the document, filled a SAPscript or Smart Form, and handed the result to the spool, to SAPconnect for email, or to an IDoc for EDI. Requirement routines maintained through VOFM decided when an output was proposed at all. Thirty years of customer-specific behaviour accumulated in exactly those places: copied print programs, custom routines, and Z output types with their own condition tables.

S/4HANA output control replaces each of those parts. Determination is a BRF+ application maintained through Output Parameter Determination (transaction OPD), where decision tables decide output type, receiver, channel, form template, printer, and email settings from document attributes. Rendering uses a form template bound to a form data provider, with Adobe Forms as the primary technology and later support for Smart Forms and SAPscript under restrictions, and there is no print program in the classic sense. Every output becomes an output item with its own status and log, visible and reprocessable from the Output Items Fiori apps, instead of a NAST row inspected through VF31 or the document's output screen. Channels cover print, email, XML, and, in later releases, IDoc for EDI.

Does NAST actually stop working after a conversion?

No, and this is the point most conversion plans get wrong in one of two directions. SAP Note 2228611 describes the new framework as the strategic direction while keeping NAST-based output available in on-premise S/4HANA, and the activation is per application object type: billing documents, sales documents, outbound deliveries, and purchase orders can each be left on NAST or switched to output control through the application object type activation view. Some newer S/4HANA functions, Settlement Management among them, use only the new framework, so an estate that adopts condition contracts for rebates already has output control running whether the SD team planned for it or not.

The two failure modes are a project that assumes everything must be rebuilt in output control before go-live and budgets a form factory it does not need, and a project that assumes nothing changes and discovers after conversion that a default activation, a new application, or a Fiori app is producing output through a framework nobody configured. The Simplification Item Check flags the output management item so the topic is raised, but it does not decide the strategy for you; that is a per-application choice the project has to make and record.

What in your ECC estate is affected

The blast radius of an output decision is wider than the forms themselves. Reading it from the live system rather than from memory is what makes the scope believable.

• Output types and condition records. Every active output type in NACE, its access sequence, and the condition records that carry live routing decisions such as which customer gets EDI and which gets email. Many estates have dozens of Z output types of which a handful still fire.
• Print programs and forms. Customer copies of the standard print programs, the SAPscript and Smart Form objects they drive, and the includes where pricing, texts, and partner data are massaged before printing. In output control there is no program; that logic moves to the data provider, the form template, or disappears.
• VOFM requirement routines. Routines in the output area decide whether an output is proposed at all. In output control the same rule is a condition in a BRF+ decision table, which is more transparent and less expressive, so some routines translate cleanly and some encode logic that should be questioned.
• Interfaces. EDI output that runs through message control to an IDoc, and any middleware that keys on NAST status or on a specific message type, needs a mapping to the new channel or a deliberate decision to keep the application on NAST.
• Operational habits. Reprocessing failed output, reprinting for a customer, and month-end output runs all live in different transactions and apps under the two frameworks, and the people who do that work need to know which framework a given document is on.

Reading the output estate from the live system

Everything above is queryable. The output types and procedures live in configuration tables, the condition records in the condition tables behind each access sequence, the routines in VOFM, and the print programs and forms in the repository with where-used relationships to the includes and tables they touch. The question a project actually needs answered is not how many output types exist but how many produced output in the last twelve months, through which medium, for which document types, and driven by which custom code. NAST itself carries that history, one row per output attempt with a status.

Our agents read that through governed, read-only tool calls against the live system: the active output types and their volumes from NAST, the condition records that route them, and a where-used pass over the print programs, routines, and forms with the business rule inside each object read from source. On a reference estate, a live ECC system we use to validate the method rather than any customer's result, 44% of custom objects were retirement candidates, and output logic that copied a standard program to change one text block is a typical member of that bucket. A customer's numbers come from their own system. Where the outcome is target configuration, such as the application object type activation or BRF+ determination content, the agent drafts a governed customizing transport and the customer's change board decides whether it lands; development systems only, never touching production on its own. A functional-testing agent that would generate a converted form against real documents and compare it to the ECC output is in build and design preview, not shipped.

A working sequence for the output decision

Start with the inventory ranked by volume: which output types fired, how often, through which channel, and from which custom program. Retire the ones that did not fire before anyone discusses converting them. Then make the per-application switch decision explicitly, with a sales, purchasing, and logistics owner each signing their own applications: stay on NAST for the conversion and move later, or move now and absorb the form rebuild in the project. Either is defensible; leaving it implicit is not. For the applications that move, map each surviving form to keep, rebuild in Adobe Forms with a data provider, or replace with the delivered template, and translate each VOFM routine into a BRF+ condition or retire it with the evidence attached. For the applications that stay, record the decision and the trigger that will revisit it.

SAP's agent-led transformation capabilities announced at Sapphire 2026, with a stated reduction of more than 35% in migration effort (SAP News), are aimed at simplification items of exactly this shape, where the technical change is bounded and the effort is in deciding what the estate should still do. Whether that tooling runs inside RISE with SAP or as comparable agentic capability on an S/4HANA system a customer operates on AWS is an ownership choice. The output decision is the same either way: NAST keeps working, and every output type still has to earn its place.