Output Management Shift from NAST to BRF+
S/4HANA introduces a new output management framework built on BRF+ rules instead of the classic NAST message control used in ECC. Output determination, form assignment, and channel selection (print, email, EDI, fax) move from condition-technique records maintained through NACE and VV11-VV13 into BRF+ decision tables, though NAST remains active for some document types depending on release and configuration, creating a hybrid landscape that must be deliberately managed.
This page covers the shift from NAST-based message control to the BRF+ output management framework in S/4HANA for sales and billing documents. It focuses on what breaks in custom print programs, EDI triggers, and batch jobs when the underlying determination logic changes, and what a conversion project must decide before go-live rather than clean up afterward.
Published 16 Sept 2026· 1,207 words
Classic ECC behaviour
In ECC, output for sales orders, deliveries, and billing documents runs through message control on the NAST table. Output types are configured in NACE, condition records are maintained through VV11, VV12, and VV13, and each record ties an output type to a partner function, transmission medium, and processing time. A processing routine, typically a function module tied to a print program and a SAPscript or Smart Form, fires when the record is processed, either immediately at save or later through the batch report RSNAST00. EDI and IDoc-based output for partners uses the same mechanism, with the medium set to EDI and the partner profile picking up the message. Repeat output, whether reprinting an invoice or resending an EDI message, is done through document-specific output transactions such as VF31 for billing. This whole chain is condition-technique based, familiar to anyone who has worked pricing, and reused deliberately by SAP for that reason. Custom output types built on this framework are common in every landscape, often with heavily modified print programs.
S/4HANA behaviour
S/4HANA introduces an output management framework where determination logic is expressed in BRF+ decision tables rather than NAST condition records. A document type is assigned an output determination procedure that calls a BRF+ function, which evaluates rules against document data and returns the output type, channel, and form. Forms move toward Adobe Forms rather than SAPscript or Smart Forms, though existing forms can often be reused with adaptation. The new framework is rolled out document type by document type across releases, meaning billing output was moved first in many landscapes while deliveries and sales order confirmations continued running on classic NAST for longer. The practical result is a hybrid system: some document types use BRF+ output management, others still use NAST, and the split depends on the release and on which switches or business functions were activated during conversion. There is no single cutover date; it is a configuration decision made per document category. Authorization and monitoring tools differ from NACE and RSNAST00, and troubleshooting a non-firing output now means opening the BRF+ application and tracing rule evaluation rather than checking a condition record.
Project impact
The disruption is concentrated wherever output logic was customized or wired into downstream processes.
- Custom print programs and Smart Forms attached to NAST processing routines do not automatically carry over; if the document type moves to BRF+, the routine that used to fire them is gone and the form has to be reattached through the new determination path.
- EDI and IDoc output for customers and carriers, previously triggered through NAST medium settings and partner profiles, needs to be re-verified end to end; a silent failure here is not caught in functional testing, only when a partner stops receiving invoices in production.
- Batch jobs scheduled around RSNAST00 for the migrated document types either stop finding records to process or run against an empty queue, and nobody notices until someone asks why overnight output volumes dropped.
- Users accustomed to VV11-VV13 for creating condition records, or to repeat-output transactions built on NAST, find those screens no longer control the document types that moved, and raise incidents believing output is broken rather than relocated.
- Authorizations built around NAST-related objects do not extend to BRF+ output management; support and print-operations teams may lose the ability to reprint or resend output they used to control themselves.
- Month-end billing runs that rely on mass output processing can behave differently under BRF+ rule evaluation, particularly if volume-dependent performance was never tested at real month-end scale.
Migration actions
The first decision is not technical, it is scoping: which document types will move to BRF+ output management and which stay on NAST for this release. That decision is a pre-conversion gate because it determines whether custom output development is rebuilt now or deferred.
- Inventory every custom output type, its processing routine, its form, and every partner or interface consuming it, before touching configuration.
- For each document type in scope for the move, confirm whether SAP delivers a standard BRF+ determination or whether one has to be built, and treat the build as a project task with its own testing cycle, not a side activity.
- Rebuild or reassign forms, moving to Adobe Forms where the target document type requires it, and retest layout and data binding rather than assuming a lifted SAPscript form renders identically.
- Re-point every EDI and IDoc-triggered output through the new determination path and re-test with the actual partner, not a simulated one, including error and retry handling.
- Reconfigure batch scheduling so background output processing targets the correct framework per document type, and update any monitoring dashboards built around NAST record counts.
- Run a full volume test at expected month-end billing load before go-live; BRF+ rule evaluation at scale behaves differently from single-document testing.
- Communicate the change to end users who reprint or resend output manually, since their transaction may no longer apply to the document type they are working.
Whose problem this is
This is a joint call. Functional SD leads decide which document types move and when, based on business risk to invoicing and EDI-dependent customer relationships. Technical and forms teams own rebuilding print programs, BRF+ rules, and Adobe Form layouts. Neither side can make the scoping decision alone, and it should be locked before the technical build starts, not discovered mid-development.
Common pitfalls
The most common failure is partial migration left unmanaged: billing output runs on BRF+ while delivery output stays on NAST, and support staff keep troubleshooting both as if they were one system.
- Old NAST condition records left active for a document type that has already moved, producing confusing duplicate or missing output that only shows up when both paths are checked side by side.
- EDI partner profiles that were never updated to reflect the new determination path, passing functional test with a handful of test messages but failing under production message volume or with a real trading partner's message format.
- Forms that render correctly in test with sample data but break on production documents carrying long text, multiple line items, or characters the new form template does not handle.
- Authorization gaps discovered only when a support user tries to reprint an invoice during a live customer call and finds no transaction that lets them.
- Performance of BRF+ rule evaluation tested only against a handful of documents, then run against a full month-end billing batch, where rule complexity multiplies runtime in a way single-document testing never revealed.
- Assuming the move is a one-time cutover rather than a document-type-by-document-type configuration state that has to be tracked and documented for every future release upgrade.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-s4hana-changes/output-management-moves-from-nast-to-brf-plusERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.