VF31 — Issue Output for Billing Documents
VF31 is the mass output-processing transaction for billing documents. It does not create or change a billing document; it reads billing documents that already exist, runs output determination against them, and issues or reissues the associated print, email, fax, or IDoc output by writing or updating entries in the NAST message log.
This page covers VF31, the transaction consultants use to reissue or troubleshoot output (invoice print, IDoc, email) for billing documents that have already been posted. It focuses on why output silently fails to generate, why reissue does nothing, and the common but wrong reflex of cancelling and rebilling to force output out.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,075 words
What it does
VF31 selects existing billing documents and runs output determination against them, generating or reissuing messages such as invoice print, customer email, fax, or EDI/IDoc output. It writes to the same output log table used by all classic SAP output processing, regardless of application. The structural fact that causes most confusion: VF31 never creates or modifies a billing document itself. It only acts on output records tied to a billing document that already exists in the system. If the billing document is missing, wrong, or not yet released to accounting, VF31 cannot fix that, and running it repeatedly will not change the underlying billing data, only the output status attached to it.
When it is used
VF31 is reached when a customer reports an invoice was never printed, an EDI invoice never arrived, or an email confirmation of a billing document was not sent, and the billing document itself is confirmed correct. It sits downstream of VF01/VF04 billing creation, used specifically to repair or repeat the output step without touching the financial posting. It is also used for scheduled mass reissue runs, for example resending a batch of billing documents after an output type's form or partner profile was corrected. For a single document where the output tab is already open, a consultant typically uses the output tab inside VF02/VF03 instead; VF31 is the tool for mass or repeat runs across many documents.
How to use it
- Enter the selection screen with billing document number or number range, sales organization, billing type, and the output type to be processed
- Decide whether to select only unprocessed output or also already-processed output (repeat processing flag), since the default view usually hides output already marked as sent
- Choose the processing mode: display log only, process in dialog, or schedule as a background job for large volumes
- Execute and review the resulting log, checking status per document and per output type before assuming success
- For failures, drill into the individual output record to see the error returned by the print program, IDoc port, or email step
Key fields
- NAST - the message/output status log; every output record VF31 creates or updates lives here, keyed by application, output type, and object key (billing document number)
- VBRK - billing document header, read to determine which documents are in scope and whether output determination is relevant for that billing type
- VBRP - billing document item data, read where output determination or the form depends on item-level content
- TNAPR - configuration of output types, linking output type to the print program, form, and processing routine used when VF31 triggers the message
How to prove it in the data
Query NAST filtered on the billing document number in the object key field, application set to the billing application, and the specific output type in question. Compare the status field and processing flag against the timestamp fields to see whether a record exists at all, whether it was ever marked as processed, and when. No NAST record for the billing document means output determination never fired for it; a NAST record with an unprocessed status after a VF31 run that reported success means the downstream dispatch (print spool, IDoc port, email gateway) failed, not the SD determination step.
ECC vs S/4HANA
VF31 exists on S/4HANA and behaves the same way as in ECC; billing document output still runs on classic NAST-based output determination unless a customer has specifically migrated a given output type to the newer BRFplus-based output management framework. There is no dedicated Fiori app that replaces VF31 for mass reissue of billing output; display-oriented Fiori apps exist for viewing invoices, but the reprocessing workflow itself is still run from the GUI transaction.
Common pitfalls
- No output record at all: check first whether the output determination procedure is even assigned to the billing type, and whether a valid condition record exists for the combination of sales organization, output type, and partner or customer used on the document. Missing condition record produces silence, not an error message.
- VF31 log shows success but the customer never received anything: this is a downstream delivery failure, not an SD configuration issue. Check the email gateway, IDoc port and partner profile, or print spool, and hand it to Basis or the interface team rather than re-running VF31 repeatedly expecting a different result.
- Reissue does nothing: by default VF31 only selects output that has not yet been processed. An output type already marked as sent will not reappear unless the repeat-processing option is explicitly selected on the selection screen.
- Wrong reflex, cancelling and rebilling: consultants under pressure sometimes cancel the billing document with VF11 and recreate it just to force new output. This creates unnecessary reversal postings and duplicate accounting documents when the real problem was output determination, which VF31 could have resolved without touching the financial document at all.
- Time-bound condition records: an output condition record with a validity period that does not cover the billing date, or an output type deactivated for a sales organization after a cutover, silently prevents output generation even though the same output type works for older documents.
Whose problem this is
Primarily a functional SD problem: output determination customizing, condition records, and partner assignment belong to the SD/O2C consultant. Once NAST shows a record moved to a failed technical status (spool, IDoc, or email transport error), ownership shifts to Basis or the interface/PI team. A good handover includes the billing document number, output type, the NAST status and timestamp, and whether the failure is at determination (no record) or dispatch (record exists, not delivered).
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/vf31ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.