Agree what counts as an order
Before anyone builds a report, settle one question: which orders count. Two people pulling "orders in June" and getting different answers is almost never a software problem. It is two unstated definitions.
The four decisions
1. Which status counts
An order in the Revenue Cloud carries three independent statuses:
| Field | Values | What it tells you |
|---|---|---|
status | pending, placed, in_fulfillment, completed, cancelled | Where the order is in its life |
payment_status | open, pending, authorized, paid, partially_paid, refunded, failed | Whether the money arrived |
fulfillment_status | unfulfilled, partial, fulfilled | Whether the goods left |
pending means the order exists but has not been placed: an abandoned or
in-flight checkout. It should never appear in a revenue figure. Beyond that you
have a real choice:
- Count from
placed. Commercial reality: the customer committed. This is what sales wants, and it is the right basis for a digitalisation KPI. - Count from
completed. Delivered and done. Closer to what finance recognises, and it lags by however long fulfilment takes.
Pick one, write it down, and use it in every report. Mixing them across reports is the most common cause of two numbers that will not reconcile.
2. What happens to cancellations and returns
Cancellations move an order to cancelled with a cancelled_at timestamp.
Returns are recorded separately, against an order that already completed.
Decide whether a cancelled order disappears from the month it was placed in, or stays and is offset. Both are defensible; only one can be true in your reports. The same for returns: net revenue means returns are subtracted, gross revenue means they are not. Label every revenue figure with which one it is.
3. Gross or net
An order carries subtotal, shipping_total, tax_total and grand_total.
For German B2B the usual reporting basis is net: subtotal, excluding VAT and
usually excluding shipping, because that is what the ERP reports and what
margin is calculated on. grand_total is what the customer paid.
Whichever you choose, use the same one everywhere. A shop figure built on
grand_total next to an ERP report built on net revenue will differ by
19 percent and cost somebody an afternoon.
4. Which orders are real
Exclude your own test orders, and decide where internal or sample orders sit. The cheapest way to keep this clean is a dedicated organization for internal orders, so they can be filtered out by account rather than by remembering which order numbers were tests.
Make non-shop orders visible
The most valuable B2B metric, the share of orders arriving through the shop rather than by phone or email, only works if orders that did not come through the shop still reach the platform.
Every order carries a channel_id. Set up a
channel for each route your orders arrive by, including
the manual ones, and make sure orders the Innendienst keys into the ERP flow
back with that channel set. Without this, your reporting sees only shop orders
and every digitalisation figure reads 100 percent.
Settle which system creates the order record first. See Deciding your system of record.
What to check
Take one closed month. Filter the order list in Commerce Studio › Order Management › Orders to that month and note the count and the subtotal, then pull the same month from your ERP. They will not match on the first attempt. Work through the difference until you can name every euro of it: status boundary, tax, shipping, cancellations, test orders. When you can explain the gap, you have a definition. Write it down where the next person building a report will find it.