8.2 Order-Related vs. Delivery-Related Billing, Invoice Splits, and Collective Invoicing

Order-Related vs. Delivery-Related Billing, Invoice Splits, and Collective Invoicing

In SAP S/4HANA Sales, an enterprise must bill diverse commercial offerings—ranging from tangible bulk goods and assembled machinery to intangible professional services, software licenses, warranties, and milestone-based construction contracts. To manage these operational variations, SAP provides two primary billing methods: Delivery-Related Billing and Order-Related Billing.

Furthermore, when processing hundreds of daily shipments to high-volume commercial buyers, enterprises seek to consolidate multiple shipments into a single Collective Invoice to reduce administrative costs and streamline payment processing. However, when transactional attributes differ, the billing engine automatically triggers an Invoice Split. Mastering billing methods, copy control routines, and split criteria is essential for configuring an efficient Order-to-Cash workflow.

---

Billing Relevance at the Item Category Level (TVAP-FKREL)

The billing method applied to a sales line item is not configured at the sales document header level; rather, it is controlled at the Item Category level in database table TVAP through the Billing Relevance indicator (FKREL).

Sales Document Header (OR) 
  ├── Line 10: Material M-01 (Item Cat TAN) ──> FKREL = 'A' (Delivery-Related Billing)
  └── Line 20: Service S-01  (Item Cat TAD) ──> FKREL = 'B' (Order-Related Billing)

Key Values of Billing Relevance (FKREL)

---

Deterministic Invoice Split Criteria

When a billing clerk runs transaction VF04 or an automated background job (VF06) processes 50 outbound deliveries for the same customer, the business typically expects a single consolidated monthly or weekly invoice. However, the system often generates multiple distinct billing documents. This phenomenon is known as an Invoice Split.

The Fundamental Architectural Rule

An SD billing document is persisted in two primary database tables:

• VBRK: Billing Document Header
• VBRP: Billing Document Line Items

A billing document can contain thousands of line items in VBRP, but every line item within that billing document must share identical header fields in VBRK. If the deliveries selected for billing contain disparate header attributes, the database cannot physically store them under a single VBRK record. Therefore, the billing engine is mathematically compelled to initiate an Invoice Split.

Inviolable Header Split Fields in Table VBRK

The following header fields represent inviolable split criteria hardcoded into the SAP billing kernel. If any of these fields differ across preceding deliveries or orders, an invoice split is guaranteed:

1. Payer (VBRK-KUNRG): The partner function Payer (PY) responsible for settling the invoice. Even if two deliveries share the identical Sold-to Party (AG), if their master data assigns different Payers, they must split.
2. Billing Date (VBRK-FKDAT): The accounting date assigned to the invoice. If Delivery 1 is scheduled for billing on October 10th and Delivery 2 on October 15th, they will split unless the user overrides the date during batch execution.
3. Country of Destination (VBRK-LAND1): The destination country used for tax jurisdiction. Deliveries routed to domestic vs. international export destinations cannot be combined.
4. Terms of Payment (VBRK-ZTERM): Payment terms (e.g., NT30 Net 30 days vs. 0002 2% 10 / Net 30). An invoice can have only one set of payment baseline dates and cash discount terms.
5. Billing Document Currency (VBRK-WAERK): Transaction currency (e.g., USD vs. EUR). An invoice header can support only one commercial currency.
6. Sales Area (VBRK-VKORG, VTWEG, SPART): Sales Organization, Distribution Channel, and Division. An invoice header is legally bound to a single Sales Area.
7. Incoterms (VBRK-INCO1, INCO2): Delivery terms and location (e.g., FOB Chicago vs. DDP Munich).
8. Exchange Rate for FI (VBRK-KURRF): Fixed currency conversion rate between transaction currency and company code local currency.
9. Tax Classification / Destination VAT Registration Number (VBRK-STCEG): Tax identification number required for statutory cross-border European Union reporting.

Outbound Delivery 80001050               Outbound Delivery 80001051
- Sold-to: 100050                        - Sold-to: 100050
- Payer: 100050                          - Payer: 100050
- Terms: Net 30 (ZTERM: NT30)            - Terms: 2% 10 Net 30 (ZTERM: 0002)
- Billing Date: 2026-10-15               - Billing Date: 2026-10-15
                 │                                        │
                 └──────────────────┬─────────────────────┘
                                    │
                                    ▼
                       [ Billing Due List Execution ]
                                    │
                     Mismatched Field: VBRK-ZTERM!
                                    │
                  ┌─────────────────┴─────────────────┐
                  ▼                                   ▼
      [ Invoice 90000012 ]                [ Invoice 90000013 ]
      - Payer: 100050                     - Payer: 100050
      - Terms: NT30                       - Terms: 0002

---

Customizing Split Criteria via Copy Control Data Transfer Routines

In addition to the standard database header fields, an invoice split can be intentionally created—or prevented—through Data Transfer Routines configured in Copy Control (transactions VTFL and VTFA).

When copying data from a delivery or sales order into an invoice, the system executes an ABAP data transfer routine (defined in transaction VOFM under Data Transfer → Billing Documents). This routine populates structure VBRK:

• Routine 001 (Inv. Split Sample): The standard routine. It populates VBRK with standard header values, permitting collective consolidation as long as baseline commercial fields match.
• Routine 003 (Single Invoice): Creates one billing document per reference document. According to the official course, data transfer routine 3 writes the number of the reference document into the split field VBRK-ZUKRI; because that number differs for each document, the documents can no longer be combined.
• Custom Data Transfer Routines (VOFM): Enterprises can build bespoke routines to split invoices based on arbitrary business rules, such as customer Purchase Order number (BSTKD), manufacturing plant, or project WBS element.

---

Diagnosing Splits: The Split Analysis Tool

When a collective billing run unexpectedly generates multiple invoices for a customer, functional consultants do not need to perform manual table dumps. SAP provides an embedded diagnostic tool called Split Analysis.

How to Execute Split Analysis

1. In transaction VF01 (Create Billing Document) or VF04 (Maintain Billing Due List), enter or select the multiple deliveries/orders.
2. Execute billing simulation or navigate to menu path: Environment → Split analysis.
3. The system presents a side-by-side comparison matrix of the generated invoices.
4. Split Analysis compares table VBRK across both documents and explicitly highlights the differing fields in red, explaining exactly why consolidation failed (e.g., VBRK-FKDAT differs, or VBRK-INCO2 has divergent city names).

+--------------------------------------------------------------------------+
| Split Analysis Diagnostic Screen                                         |
+--------------------------------------------------------------------------+
| Billing Document 90000045 <-> Billing Document 90000046                  |
|--------------------------------------------------------------------------|
| Field Name     Description               Doc 90000045      Doc 90000046  |
|--------------------------------------------------------------------------|
| VBRK-KUNRG     Payer                     0001000050        0001000050    |
| VBRK-VKORG     Sales Organization        1010              1010          |
| VBRK-ZTERM     Terms of Payment          NT30              0002 [SPLIT]  |
| VBRK-FKDAT     Billing Date              2026-10-15        2026-10-15    |
+--------------------------------------------------------------------------+
| Result: Split caused by differing Terms of Payment (VBRK-ZTERM)           |
+--------------------------------------------------------------------------+

---

Invoice Consolidation Strategies

To successfully achieve collective billing and combine multiple shipments into a single invoice, organizations employ three primary configuration strategies:

1. Overriding Billing Date in Collective Execution (VF04 / Fiori)

Deliveries created on different days naturally carry different planned billing dates (LIKP-FKDAT). To prevent date-based splits, the billing user or background batch job can enter a unified Default Billing Date on the VF04 selection screen. The billing engine overwrites each delivery's individual date with this common date, aligning VBRK-FKDAT across all line items and enabling consolidation.

2. Invoicing Schedules via Factory Calendars (KNVV-PERFK)

In the Business Partner master (role FLCU01, Sales Area → Billing tab), enterprises assign an Invoicing Dates key (PERFK). This key points to a specialized factory calendar that designates specific commercial invoicing days (e.g., every Friday, or the 15th and last day of each month). All orders and deliveries created during the period automatically snap to the next scheduled calendar date, synchronizing VBRK-FKDAT.

3. Invoice Lists (LR / LG)

If deliveries must be billed immediately upon shipment (generating separate F2 invoices for transportation documentation), the enterprise can consolidate those individual invoices at month-end into an Invoice List (document type LR). The invoice list generates a collective financial summary sent to the payer for consolidated settlement.

---

Copy Control in Billing (VTFL & VTFA)

Copy Control is the central customizing engine governing how data flows from preceding logistics documents into billing documents. Configured via:

• VTFL: Outbound Delivery to Billing Document (e.g., Delivery LF to Invoice F2)
• VTFA: Sales Order to Billing Document (e.g., Sales Order OR to Invoice F2, or CR to Credit Memo G2)

Copy control is maintained at both Header Level and Item Level.

Key Parameters at the Item Level

The official course gives the standard billing quantities:

For delivery-related billing, the quantities come from the delivery while the prices come from the underlying order.

The Pricing Type Parameter: Deep Dive

The Pricing Type parameter in copy control is one of the most vital customizing switches in SD, determining whether historical sales order prices are preserved or recalculated at billing time:

• A (Copy pricing components and redetermine scales): Copies base condition rates from the sales order but recalculates quantity scale tiers based on the total billed quantity.
• B (Complete redetermination): Completely wipes historical sales order pricing and re-reads all condition tables from scratch using the current billing date. Used when regulations require pricing to reflect spot-market commodity rates on the exact day of invoicing.
• C (Copy manual pricing elements and redetermine the rest): Retains manual discounts or surcharges entered by sales reps while recalculating base prices and taxes.
• D (Copy pricing components unchanged): Exactly copies all condition amounts, rates, and values from the preceding document without recalculation.
• G (Copy pricing components unchanged and redetermine taxes): Preserves the prices and discounts negotiated in the sales order but determines the tax conditions again, for example because the tax situation at billing differs from the order.
• H (Redetermine freight conditions): Preserves base prices and taxes but recalculates freight conditions (KF00) based on actual shipped delivery weight.

---

Practical Scenario: Mixed Order Fulfillment

Consider an enterprise selling industrial machinery accompanied by an on-site installation service:

• Sales Order Item 10: Assembly Robot ($80,000, Item Category TAN, FKREL = A)
• Sales Order Item 20: Calibration & Training Service ($10,000, Item Category TAD, FKREL = B)

How Billing Unfolds:

1. Service Item 20 (TAD): Because FKREL = B, this item does not enter the shipping delivery queue. It immediately appears on the Billing Due List (VF04) under order-related billing. It can be invoiced immediately upon sales order confirmation.
2. Robot Hardware Item 10 (TAN): Because FKREL = A, the system blocks invoicing until an outbound delivery (LF) is created, picked, packed, and posted with Goods Issue (PGI). Only after warehouse PGI moves the inventory does Item 10 enter the Billing Due List.
3. Result: Unless held by a billing block, the customer receives two invoices: an order-related invoice for the installation service and a delivery-related invoice for the physical robot.