Order source and dining option: two fields your reporting rests on
In short
Dining option describes how the food leaves the building — dine-in, takeaway, delivery, curbside — and drives tax, kitchen routing and packaging. Order source describes where the order came from, and drives attribution. An integration that sets one and defaults the other produces a month of orders indistinguishable from walk-in trade.
Key takeaways
- Dining option drives tax, routing and prep. Order source drives attribution. Neither substitutes for the other.
- One source value per channel, forever. A shared "online" value cannot be split apart later, because the checks are already written.
- Never encode the channel into the dining option — a delivery value that means "came from an aggregator" corrupts the tax base.
- Treat an unknown source value as an error, not a default. Defaulting to walk-in is the most expensive default in the integration.
Dining option answers how the food leaves: eaten in, carried out, delivered, handed through a car window. Order source answers where the order came from: your own site, the phone, a kiosk, a specific marketplace. The POS uses the first to compute tax, route tickets and prompt for packaging; the business uses the second to work out which channel is worth anything. Set the wrong dining option and a guest gets taxed wrong today. Set the wrong source and nobody notices until the first report that cannot answer a channel question.
Vocabulary differs by platform, so confirm the exact names and permitted values against the developer reference for the till you are integrating with. Square's Orders API, for example, documents an order `source` and 4 fulfilment types — Pickup, Shipment, Delivery and In-store — while other platforms model the same 2 ideas under different names and with different lists.
How the food leaves: the field with same-day consequences
The dining option is read by more of the restaurant than anyone expects. It selects the tax treatment, because many jurisdictions tax food differently when it is eaten on the premises. It selects prep behaviour: a takeaway coffee is made in a lidded cup and a dine-in one is not. It affects routing, because a delivery ticket may need to print at a packing station that a dine-in ticket never touches. And in table service it decides whether a check is attached to a table at all.
That is why the value has to be true rather than convenient. A common shortcut — sending everything from the web channel as takeaway because it is the value that works — quietly misprices dine-in orders placed at the table from a QR code, and hides the covers those orders represent. Dine-in orders are also the ones that feed the covers count under the number every seating decision rests on, so a wrong value distorts capacity planning as well as tax.
Where the order came from: the field nobody validates until month end
Order source is metadata about origin, and it has no same-day symptom at all. Orders arrive, food goes out, money lands. The failure appears the first time somebody asks what share of covers came through the first-party channel versus an aggregator, or which channel a promotion actually moved — and the answer requires splitting checks that were all written with the same value.
Five systems, and which of the two fields each one reads
| Consumer | Reads | Failure when the value is wrong |
|---|---|---|
| Tax engine | Dining option | A wrong rate on the guest's receipt, repeated silently until an accountant finds it |
| Kitchen routing and prep | Dining option | Tickets print at the wrong station, or packaging prompts never fire |
| Channel-mix reporting | Order source | Online orders appear as counter trade and the first-party channel looks like it does no volume |
| Commission and margin analysis | Order source | Aggregator orders and own-channel orders sit in one bucket, so nobody can compare margin per channel |
| Marketing and loyalty attribution | Order source | A campaign cannot be tied to the orders it produced, so the next budget conversation is opinion |
A tagging scheme that stays separable in 3 years
- Give every channel its own source value from day 1 — own website, own app, phone agent, kiosk, and each marketplace named individually. Aggregation is a reporting operation and it is reversible; a shared value is not.
- Never encode the channel into the dining option. "Delivery" must mean the food is delivered, not that an aggregator sent it, or the tax base moves with your commercial arrangements.
- Keep a written registry of permitted values with an owner, and treat adding a value as a change that needs a decision rather than a deploy.
- Send both fields explicitly on every injected order. Relying on a POS default means the default becomes your policy the day somebody changes it in a store — which is also how an integration that works at one location fails at the other four starts.
- Store the values you sent on your own order record, next to the returned check id, so a report mismatch can be traced to a specific ticket rather than argued about.
- Alert on unknown or missing values instead of substituting one. An order that arrives with no source is a bug you can fix this week; a default is a bug you find in 8 months.
Steps 4 and 5 both depend on a stable identity map between your catalogue and the till's, which is the artefact described in external IDs and the mapping table nobody designs until it breaks. Whether you can write these fields at all in production is upstream of every one of these steps, and is settled by what a POS partner programme actually gates.
What changes when there are 12 locations instead of 1
Permitted values are usually configured per location, which means location 7 can be missing the curbside option that the other 11 have, and orders to that store will fail or fall back. The check to run before launch is boring and rarely run: pull the permitted dining options and sources for every location, diff them against each other, and treat any difference as a configuration bug rather than local colour. It takes an afternoon and it removes an entire class of go-live incident.
A first-party ordering channel is worth building only if you can prove what it produced, and these 2 fields are the proof. That is why we treat them as scope in a product build rather than as a configuration detail discovered during testing.
A wrong dining option gets caught by a guest reading a receipt. A wrong order source gets caught by a finance director 8 months later, and by then there is nothing to fix, only something to regret.
Decide both values consciously, send both explicitly, and never let a default make the decision. The rest of this silo sits under integrating with the POS on the counter, inside our restaurants and food service practice.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
What is the difference between order source and dining option in a POS?
Dining option describes how the food leaves — dine-in, takeaway, delivery, curbside — and the POS uses it to compute tax, route tickets and drive prep behaviour. Order source describes where the order originated, such as your website, a phone agent, a kiosk or a named marketplace, and it exists for attribution. One has same-day operational effects, the other only shows up in reporting.
Why do our online orders show up as walk-in sales?
Almost always because no order source was sent and the POS applied its default, which is usually the value the terminal itself uses. The orders were accepted, the food went out and the money reconciled, so nothing looked wrong until a channel report was needed. Fix the injection to send an explicit source per channel, and treat a missing value as an error rather than letting a default stand in.
Can we split one shared online source value apart later?
Not from the POS data alone. The checks already written carry the shared value and nothing in them distinguishes the channels. If your own system stored the check id returned at acceptance, you can join to your order records and reconstruct the split for orders you created — but orders from any channel you did not create are unrecoverable.
Should a delivery from an aggregator use the delivery dining option?
Yes, because the food genuinely is being delivered, and the tax and packaging behaviour should follow that fact. The aggregator's identity belongs in the order source instead. Keeping the 2 fields independent is what lets you compare margin on delivery across channels without disturbing how tax is computed.
- pos
- reporting
- attribution
- restaurants
The work behind this page
Builds from our portfolio that this page draws on.
Read next
- External IDs: the mapping table nobody designs until it breaksThe identity map between your catalogue and the till is the contract that makes every order possible, and 4 routine events break it silently. Design it as a versioned artefact.definition
- It works at the first location and returns an auth error at the other fourIdentical code, one store working and four rejecting, means authorisation was granted per merchant location and only completed once. The fix is an inventory, not a retry.diagnostic
- The full menu sync hits the limit before it finishesA sync that works on a 40-item menu and dies on a 400-item one is not too big. It is making one request per item, at the same minute as every other location.diagnostic
- The order lands in the POS and nothing prints at the stationThe POS accepted your order and the line never saw it. Routing is configuration — dining option, revenue centre, station map — and no field in your payload can override it.diagnostic
- The POS says it sent the event and your system never movedA status event that arrives after service is worth nothing. Five places it dies before your handler, and why the durable fix is a polling sweep over open orders rather than better webhook code.diagnostic
- What a POS partner programme gates, and what it does notA partner programme is a commercial gate wearing technical clothing. It controls scopes, production credentials and listing — and the wait is somebody else's decision, not engineering.definition
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation