Output Management in SAP S/4HANA (BRF+)
NACE vs BRF+ · output types & channels · Adobe Forms · troubleshooting — updated for 2026
In S/4HANA, output determination stopped being a condition-record problem and became a business-rules problem. NACE gives way to BRF+ decision tables, SAPscript and Smart Forms give way to Adobe Forms, and maintenance moves into Fiori.
This guide covers how the new framework determines output, the channels available, the configuration sequence, what happened to NAST, how to run NACE and BRF+ side by side during migration, and how to troubleshoot output that never arrives.
Quick Jump
What changed in S/4HANA
For two decades, SAP output ran on the condition technique — the same machinery as pricing. You built access sequences, created condition tables, and maintained condition records in VV11 / VV21 / VV31. If output did not appear, you went looking for a missing condition record.
S/4HANA introduces a new Output Management framework where determination is driven by BRF+ decision tables. Each row is a readable business rule rather than a key combination, form output moves to Adobe Forms, email bodies come from managed templates, and maintenance sits in Fiori.
The one-line version: NACE asked “is there a condition record for this key?” BRF+ asks “which business rule applies to this document?”
NACE vs BRF+ compared
| Topic | Classic (NACE) | S/4HANA (BRF+) |
|---|---|---|
| Determination engine | Condition technique — access sequences and condition tables | BRF+ decision tables — business rules, not condition records |
| Main entry point | NACE, plus VV11/VV21/VV31 for condition records | Fiori "Output Parameter Determination" / BRF+ workbench |
| Form technology | SAPscript and Smart Forms | Adobe Forms (ADS) with Fiori-based form templates |
| Status / runtime table | NAST — one record per output on a document | APOC / Output Management tables; NAST only for legacy output |
| External send, limited body control | Managed email templates with dynamic placeholders | |
| Channels | Print, fax, EDI, external send, special function | Print, Email, XML/EDI, IDoc, plus Fiori-side preview |
How BRF+ determination works
When a business document is saved, the framework calls BRF+ and asks a series of questions. Each is answered by a decision table:
- →Should output be issued at all? The relevance rule — some documents produce no output by design.
- →Which channel? Print, email, XML/EDI, IDoc.
- →Who receives it? A partner role (sold-to, ship-to, bill-to, payer) or a derived address.
- →Which form template? The Adobe form used to render the document.
- →When? Immediately on save, or scheduled for a later batch run.
Because each answer is a rule outcome, one customer can receive an emailed PDF while another gets a printed copy and a third receives EDI — without touching a line of code.
Output channels
| Channel | Description |
|---|---|
| Physical or spool outputUses the output device / printer determined by the rules and master data. | |
| Send as email with attachmentBody comes from a managed email template; the document is attached, typically as PDF. | |
| XML / EDI | Structured B2B exchangeFor integration scenarios where a partner consumes a structured message. |
| IDoc | Classic SAP integrationStill used widely for partner and internal system integration. |
| Printer via BRF+ | Rule-derived deviceThe printer itself can be an outcome of the decision table, not just a master-data field. |
Configuration sequence
Define the output type
Create or reuse an output type for the business document (order confirmation, invoice, delivery note) and assign it to the relevant business object and process.
Assign the form and form template
Link the output type to an Adobe form template and, where relevant, an email template. This decides what the recipient actually sees.
Maintain BRF+ decision tables
This is the heart of it. Decision tables answer: should output be issued, on which channel, to which recipient, with which form and which printer? Each row is a business rule.
Define recipients / role determination
Decide who receives the output — sold-to, ship-to, bill-to, payer, or a specific email address derived from the document or master data.
Set the dispatch timing
Immediately on save, or scheduled/batch. Timing is a rule outcome, so it can differ by customer, channel, or document type.
Test end to end
Create a document, check the output preview, verify the determined channel and recipient, and confirm the issued output — then test a negative case that should produce no output.
Key T-codes
| T-code | Description |
|---|---|
| BRF+ (BRFPLUS) | BRF+ workbenchWhere the decision tables behind output determination live. |
| OPD | Output Parameter DeterminationThe maintenance entry point for output rules in S/4HANA. |
| SFP | Adobe Form BuilderCreate and maintain Adobe (PDF-based) form templates. |
| SPRO | Output Control configurationSales → Basic Functions → Output Control → Output Using BRF+ (define output types, channels, form assignment). |
| NACE | Classic output configurationLegacy. Still present for output that has not been migrated, but not the S/4HANA path. |
| VV11 / VV21 / VV31 | Classic output condition recordsSales / shipping / billing condition records — the NACE-era approach. |
| SE16N → NAST | Classic output statusRuntime status of legacy output. VSTAT 0 = not processed, 1 = successful, 2 = error. |
Forms & email templates
The form is what the customer actually sees, and this is where the technology shift is most visible:
| Technology | Status in S/4HANA |
|---|---|
| SAPscript | Legacy. Still runs, not used for new output. |
| Smart Forms | Legacy. Common in migrated systems, but not the strategic choice. |
| Adobe Forms (ADS) | The standard for the new Output Management framework. |
| Email templates | Managed templates with dynamic placeholders for the email body. |
A practical consequence: Adobe Document Services must be available and configured. Output that determines correctly but fails to render is very often an ADS problem, not a determination problem.
What happened to NAST
NAST is the classic output status table — one record per output on a document, with VSTAT showing 0 (not processed), 1 (successful), or 2 (error). For years, “check NAST in SE16N” was the standard first move when output went missing.
⚠ The trap
NAST still exists, and still holds status for legacy NACE output. But output issued through the new BRF+ framework does not behave the same way — so an empty NAST does not mean “no output happened”. Check the document’s output items and the parameter determination for BRF+ output; use NAST only for legacy.
Migrating from NACE
Most projects migrate output type by output type rather than in one cutover:
- →Inventory what actually exists. List the output types genuinely in use — projects routinely discover condition records nobody has needed for years.
- →Rebuild forms in Adobe. Recreate the layouts that are still required. This is usually the largest single effort.
- →Model the rules in BRF+. Translate the old key combinations into decision-table rows, in business language.
- →Run in parallel, carefully. Prove the new output before switching off the old — while watching for duplicates.
- →Deactivate the legacy record. Once proven, switch off the NACE condition record so customers stop receiving two copies.
Field note
The risk on an output migration is rarely technical — it is customer-facing. A duplicate invoice or a missing order confirmation is visible to the customer within hours. Migrate in small batches, and keep a rollback for each output type.
Troubleshooting
No output is determined at all
Cause: No BRF+ decision-table row matches the document, or the output type is not assigned to the business object/process.
Fix: Open the output parameter determination for that output type and simulate with the document values. A missing row is far more common than a broken engine.
Output determined but never issued
Cause: Dispatch timing is scheduled rather than immediate, or the background job that issues scheduled output is not running.
Fix: Check the determined dispatch time, then confirm the scheduled output job is active.
Email not delivered
Cause: No recipient email resolved from the partner/master data, or the outbound mail configuration (SCOT/BCS) is not set up.
Fix: Verify the recipient determination first, then the mail transmission setup. Blaming SCOT before checking recipient determination wastes hours.
Wrong form or old layout printing
Cause: The output type points at the wrong form template, or a legacy NACE output is still active alongside the new one.
Fix: Confirm the form assignment for the output type and check whether the document is producing legacy output in parallel.
Output works in test, not in production
Cause: BRF+ applications and decision tables were not transported, or production master data (printer, email) differs.
Fix: Verify the BRF+ transport landed, then compare the determining master data between systems.
Duplicate output
Cause: Both a legacy NACE output and a new BRF+ output are active for the same document.
Fix: Deactivate the legacy condition record once the BRF+ equivalent is proven.
Frequently Asked Questions
What is Output Management in SAP S/4HANA?
Output Management is the framework that decides when a business document — an order confirmation, delivery note, or invoice — should be issued, through which channel, to which recipient, and using which form. In SAP S/4HANA this is handled by the new Output Management framework driven by BRF+ (Business Rule Framework plus) rather than the classic NACE condition technique, with Adobe Forms as the standard form technology and Fiori apps for maintenance.
Has NACE been replaced in S/4HANA?
For new output, yes. SAP S/4HANA introduces a new Output Management framework based on BRF+, and that is the recommended and default approach for SD output. NACE and the classic condition records still exist for compatibility and for output that has not been migrated, so many live systems run both side by side during a transition. Saying "output is still done in NACE" in an S/4HANA context signals ECC-era knowledge.
What is BRF+ in output management?
BRF+ is SAP's Business Rule Framework. In output management it holds decision tables that determine the output: whether output should be issued, on which channel (print, email, XML/EDI), to which recipient role, with which form template, and with what dispatch timing. Instead of maintaining access sequences and condition records, you maintain rules — each row of a decision table is a readable business rule, which makes the logic far easier to change and to explain.
What is the difference between NACE and BRF+ output determination?
NACE uses the condition technique: output types, access sequences, condition tables, and condition records, with runtime status stored in NAST. BRF+ uses decision tables evaluated at runtime, maintained through Fiori or the BRF+ workbench, with Adobe Forms as the form technology and managed email templates for email bodies. Practically: NACE asks "is there a condition record for this key combination?", BRF+ asks "which business rule applies to this document?".
Which form technology is used in S/4HANA output management?
Adobe Forms (PDF-based, rendered by Adobe Document Services) is the standard for the new Output Management framework. SAPscript and Smart Forms still exist and still work for legacy output, but new output is built on Adobe form templates, which also support the Fiori-based preview and the managed email templates.
Is the NAST table still used in S/4HANA?
NAST still exists and still holds status records for classic, NACE-based output — including in S/4HANA systems that continue to run legacy output. However, output issued through the new BRF+ framework does not write its status to NAST in the same way, so troubleshooting new output by looking only at NAST will mislead you. Use the output parameter determination and the document's output items for BRF+ output, and NAST only for legacy.
How do you troubleshoot output that is not being issued?
Work in this order: (1) Was output determined at all? Simulate the output parameter determination for the document values — a missing decision-table row is the most common cause. (2) If determined, check the dispatch timing; scheduled output waits for a job. (3) For email, verify the recipient was resolved before suspecting the mail configuration. (4) Confirm the correct form template is assigned. (5) In production-only failures, check that the BRF+ transport landed and that master data matches.
Can NACE and BRF+ output coexist during a migration?
Yes, and in practice they usually do. A common migration approach is to move output type by output type: build the BRF+ equivalent, run both in a controlled test, then deactivate the legacy condition record once the new output is proven. The risk to watch is duplicate output — customers receiving the same document twice because both paths are active for the same business document.
Output is one topic. Interviews cover the whole module.
The SD Vault covers output determination — classic and BRF+ — alongside 230+ interview questions and 38 real configuration exercises, built by an SAP SD Solution Architect with 17+ years on live projects.
Get Lifetime Access →Or start free with the sample pack, Business Partner guide, and Advanced ATP guide.