BAPI_BILLINGDOC_CREATEMULTIPLE — Create Billing Documents from References

The BAPI acts on the billing document object, the same object created by transaction VF01 for single documents or VF04 for mass runs. It takes a list of references to deliveries or sales orders that are due for billing, applies the same billing type and copy control logic VF01 would apply, and generates the resulting invoice, credit memo, or debit memo header and item records. It is built for bulk processing: a single call can be handed dozens or hundreds of reference documents, each of which may produce zero, one, or several billing documents depending on split criteria such as payer, incoterms, or billing block status. It does not replace the pricing engine or copy control configuration; it triggers the same underlying logic that VF01 uses interactively.

The BAPI does not commit its own database changes. Like almost every BAPI in the sales and distribution area, it expects the calling program to issue an explicit commit, typically BAPI_TRANSACTION_COMMIT, after inspecting RETURN and deciding the run was clean. Skip the commit and the billing document numbers reported back to the caller as created will not actually persist once the session or LUW ends; the number range slot is still consumed, but no document exists at that number. This is the classic cause of an interface that reports success, hands a document number to a downstream system, and then that number turns out to be unreadable in VF03 because it was never committed.

RETURN alone does not tell the full story for this BAPI. A call processing multiple reference documents can partially succeed: some references produce billing documents cleanly, others fail on a billing block, a missing condition record, or a foreign trade data gap, and all of that lands as separate rows in RETURN, mixed together with informational messages. Checking only whether RETURN contains any type E or A message and treating everything else as a full success is the most common bug: a batch of fifty deliveries where three fail still returns a non-empty RETURN, but the other forty-seven did generate documents. The correct pattern is to reconcile the count and identity of documents in the success table against the original input list, treat any reference document missing from that success table as failed regardless of what RETURN says about it, and only then decide whether to commit the batch as a whole or roll it back entirely.

The BAPI remains callable and functionally supported in S/4HANA; it has not been formally deprecated. S/4HANA does offer a released OData-based billing document API for newer integration scenarios, and new Fiori-oriented or cloud-facing builds are generally steered toward that released API rather than the classic BAPI. For existing custom interfaces and batch billing jobs already built on this BAPI, migration is not mandatory, but any new interface work should evaluate the released API first before defaulting to the BAPI out of habit.

A failed or partial billing run is first a functional question: check copy control between the reference document type and the billing type, billing block status, and pricing procedure determination in VF01 manually against the same reference. If VF01 succeeds manually but the BAPI fails, bring the exact BILLINGDATAIN payload and the full RETURN and success table content to development; that pairing is what narrows it to an interface bug versus a configuration gap.

Mirrors transactions VF01 and VF04, and writes to the billing document header and item tables (VBRK and VBRP). Commonly chained after BAPI_OUTB_DELIVERY_CREATE_SLS when billing is delivery-related, or after BAPI_SALESORDER_CREATEFROMDAT2 when billing is order-related, since both produce the reference documents this BAPI consumes. Also sits alongside BAPI_CUSTOMERRETURN_CREATE in return-to-credit-memo flows where a return triggers a credit memo through the same billing document object.