Ship and debit

Ship and debit is a channel-rebate mechanism in B2B distribution where a distributor ships product to an end customer at a contracted price below the distributor's standard cost, then bills the manufacturer for the difference. The manufacturer "debits" itself the spread between the standard distributor price and the negotiated end-customer price, honoring the discounted price the distributor delivered on the manufacturer's behalf.

The term is most common in high-tech distribution — semiconductors, networking equipment, storage, electronic components — where manufacturers grant Special Pricing Agreements (SPAs) to compete on specific deals or in specific accounts, and distributors are the operational vehicle that delivers the contracted price.

How a ship-and-debit transaction actually works

The mechanism has four moving parts:

1. The standard price. The distributor buys from the manufacturer at a standard transfer price (the distributor net cost or DNC).
2. The contracted end-customer price. The manufacturer and the end customer agree on a deal-specific price below standard. The manufacturer documents this in an SPA.
3. The ship. The distributor ships at the SPA-contracted price. The end customer pays the distributor that contracted price.
4. The debit. The distributor submits a claim back to the manufacturer for the spread. The manufacturer issues a credit memo, settlement payment, or accrual reduction.

Why ship-and-debit is structurally difficult

Ship-and-debit looks simple in the abstract. In practice it breaks most rebate-management architectures because:

• The unit of calculation is the transaction, not the period. Most rebate platforms accrue over periods (monthly, quarterly). Ship-and-debit settles per shipment per SPA, often within days of the ship.
• The eligibility check requires line-item matching. The distributor's claim must match against SPA records by part number, customer ID, ship date, quantity, contracted price. Product-ID mismatches (ABC123 vs ABC-123), unit-of-measure mismatches, and customer-hierarchy mismatches produce constant rejection-or-overpay friction.
• The audit trail must reach to the source transaction. Auditors ask "why did we debit ourselves $X." The answer must trace to the SPA, the distributor's claim, and the end-customer transaction. If the lineage is reconstructable but not native, audit takes days.
• The volume can be enormous. A semiconductor manufacturer running ship-and-debit through 5–10 distributors might settle 50,000+ claims per quarter.

Ship-and-debit in SAP

Within SAP, ship-and-debit is typically modeled via condition records with ship-and-debit-specific condition types (often custom Z family), the condition technique matching the right SPA condition to the right shipment line, pricing procedures computing the debit amount, and Vistex or SAP IRM as the rebate engine layered on top.

How calculation-native architectures handle it

A rebate platform built on an event-sourced calculation model handles ship-and-debit differently. Each distributor claim becomes a calculation event keyed to (distributor, customer, part number, ship date, SPA). The event captures the matched SPA condition, the source distributor claim row, the standard price reference, and the resulting debit amount. The settlement push to the ERP is a separate event, lineage-tied to the original. An auditor asking "why is this debit $X" gets a database query that returns in seconds, with the four anchors attached.

This is the architectural inversion that distinguishes calculation-native from batch-ERP-resident rebate platforms — and ship-and-debit is the use case where the inversion shows up most clearly.