The $34.11 the voice agent reads out is not computed by the AI. It comes from the POS.
Every other article on this topic discusses AI for sales tax preparation software, or lists AI phone ordering vendors without explaining the one architectural decision that decides compliance: who runs the tax math when a voice agent has to quote a grand total on a call. PieLine's public demo shows the answer in 2.4 seconds of wall-clock between “Placing your order now” and “Done. Your total is $34.11.”
Why the other guides on this topic miss the actual question
Pull up the first ten articles you find on this subject. Roughly half are about using AI tools for restaurant sales-tax preparation: Avalara automation, AI bookkeeping, end-of-quarter filing. The other half are vendor pages listing AI phone ordering features in the same general bullet points. Both sets are technically on-topic. Neither answers the question an operator actually has when an AI is about to speak a dollar figure to a customer on the phone.
The question is this: when the agent says “Your total is $34.11,” whose tax logic produced that number? If the answer is the LLM, you are one rate change away from a gap between the quoted total and the committed total. If the answer is the POS, you are already as compliant as the restaurant's existing tax config, which a qualified operator has already tuned for state, city, county, channel, and item category.
PieLine made the second choice. The whole article below is a walkthrough of what that choice looks like in code, in the call transcript, and in the operator's admin panel.
The 2.4-second proof, pulled from the public repo
The file src/components/voice-activity-data.ts in the PieLine repo is a Deepgram multichannel transcription of the Denny's demo call. Two captions matter for this discussion. Their timestamps are the architecture.
Open the MP3 at public/audio/dennys-order.mp3, drop it in any audio editor, scrub to the 89-second mark, and listen to the pause yourself. If PieLine computed tax inside the LLM, that pause would not need to exist; the number would be available immediately. The fact that the agent waits before speaking is evidence that it is waiting on something external, and that something is the POS.
Two versions of the same function, only one of them is correct
Below is a sketch of what the tax math looks like if the LLM owns it versus if the POS owns it. The first is what a naive voice-agent build looks like. The second is what PieLine actually runs. Read both and ask which one you want your restaurant's name on.
Two architectures for quoting a total out loud
The model gets a subtotal, guesses at a rate, multiplies, speaks the answer. Every state rule change is a prompt change. Every multi-location operator needs per-location prompts. Every jurisdiction edge case (hot vs cold food in California, bagel-sliced-vs-whole in New York) is a hard-coded branch. Silent divergence between quoted total and receipt total is inevitable.
- Rate changes need a code redeploy
- 50 states = 50+ conditional branches
- Pickup/delivery rules encoded in prompt
- Quoted total can drift from POS total
“The total the customer hears is the total the kitchen ticket prints and the credit card is charged for. There is no second source of truth.”
PieLine architecture
How a single modifier travels from voice to the tax engine
Track one piece of revenue, the strawberry topping on the cheesecake, from the moment the customer accepts it at 65.98 seconds to the moment its tax is folded into the spoken total at 91.52 seconds.
Voice → cart → POS tax engine → spoken total
What the demo call looks like as a sequence diagram
The diagram below is the last 13 seconds of the Denny's demo call as our engineering team draws it on a whiteboard. Two things are worth noticing. The voice agent and the POS talk twice, not once. And the grand total is carried as a response from the POS, not synthesized on the voice side.
Last 13 seconds of a PieLine call
The wrong way and the right way, as code
Same demo order (Lumberjack Slam, soft drink, New York cheesecake with strawberries). Two approaches to getting to “$34.11 spoken out loud.” The first version compiles and runs. It is also the one that gets the operator in trouble at a tax rate change.
LLM does the math (do not do this)
Voice agent internally multiplies subtotal by a tax rate it got from a side table or a baked-in prompt value. Works on day one, fails on the first state rule change, the first category edge case, and the first delivery address outside the restaurant's jurisdiction. Does not ship in PieLine.
POS does the math (PieLine)
Voice agent submits a structured cart, waits on create_order, speaks the total the POS returned. Tax logic lives with the operator's POS config, where it was already maintained for every dine-in and kitchen-entered order.
Prompt-side rate table
Some vendors bake a ZIP-to-rate lookup into the prompt. Fragile: silent drift every month, impossible to audit, legally soft because the LLM is now a tax authority.
Side database of rates
Slightly better: vendor maintains a rate table in their own infra. Still wrong: two sources of truth (theirs and the POS), they can silently disagree for hours before anyone notices.
Pass the cart through, quote the response
The only approach that composes cleanly with multi-location, multi-state, multi-category restaurants. What PieLine does.
LLM-side tax math, as a code sketch
A minimal sketch of what it looks like if the voice agent tries to own the tax computation itself. This is not how PieLine works; it is here so you can see why it does not.
POS-side tax math, as PieLine actually writes it
The same computation, but the POS is the authority. The voice agent is strict about what it does: assemble a well-structured cart, post it, read the response out loud.
Jurisdiction and rule comparison
Two ways of handling the ten hardest parts of restaurant sales tax. In every row, the left column is what an LLM-as-tax-engine must do. The right column is what happens when the POS is the tax engine.
| Feature | LLM computes tax | PieLine (POS computes tax) |
|---|---|---|
| State food tax rate (CA, NY, IL, etc.) | Hard-coded in prompt or side table | POS tax config, per location |
| County and city surtax stacking | LLM has to know the full ZIP-to-rate map | POS tax config, already maintained by operator |
| Pickup vs delivery vs dine-in rules | Model needs per-state conditional logic | POS service-mode setting, POS applies the rule |
| Hot food vs cold food category rules | Needs a structured item taxonomy in the prompt | Already tagged at the POS item level |
| Alcohol excise and on-premise surcharges | Requires alcohol-aware LLM logic | POS alcohol flag drives excise automatically |
| Delivery fee taxability (FL, NY, PA differ) | Per-state exception tables in the prompt | POS delivery-fee config, set once per location |
| Rate change mid-year | Prompt redeploy at every affected location | One POS admin update, agent picks it up on next order |
| Tip taxability (varies by state) | LLM has to branch on state and tip type | POS setting per state, passthrough |
| Marketplace-facilitator status of the agent | Uncertain: does LLM-as-quoter cross the line? | Clean: the POS is the seller-side math, agent is a tool |
| Receipt with tax breakdown | Agent has to synthesize it | POS issues the receipt through its normal channel |
Same call, frame by frame, with the tax seam called out
One demo call, six moments that matter for the tax story. Watch the hand-off between the voice side and the POS side happen at frame three.
Where tax enters the call
t=45.96s — order committed to cart
Rob says “That's it. Put it under Rob.” Lumberjack Slam, eggs scrambled, sourdough, soft drink. No tax touched yet, no total calculated, no POS round-trip.
Five numbers that tell you whether your voice agent is compliant
If you are evaluating any AI phone ordering vendor, ask them to show you these five things. A vendor that can answer all of them is running the architecture PieLine runs. A vendor that hedges on any of them is probably doing the tax math in the LLM.
POS tax-config surface areas that PieLine inherits for free
Every restaurant POS exposes a tax model. PieLine never duplicates it. This is the list of operator-side settings that determine what the voice agent ends up quoting.
What happens in the edge cases every operator worries about
Four scenarios where a voice-quoted total could silently diverge from what the POS charges. Each one is resolved by the same architectural rule: the POS is the source of truth, the agent is the narrator.
Rate changed in Sacramento last week
The operator updated the rate in the POS on Tuesday. On Wednesday, the agent answers a call at the Sacramento location. The POS returns the new-rate total. The agent reads it. PieLine never knew the rate changed, and did not need to.
Delivery address crosses a county line
Destination-sourcing states tax by the delivery address. The agent collects the address, passes it on create_order, and the POS applies the correct county surtax. PieLine does not have a ZIP-to-rate table anywhere.
Prepared food vs grocery edge case
A bagel eaten in the store is prepared food; a bagel taken to go might be grocery in some states. The POS item taxonomy already encodes this. The voice agent submits channel=pickup and the POS does the right thing for the state.
Alcohol excise and age-verification gate
Alcohol items have their own excise and their own compliance gate. If the POS returns an error because the service mode is forbidden for alcohol, the agent does not fabricate a total. It routes to a human with context.
How to evaluate a voice agent on tax compliance, in ten minutes
- Ask which side of the wire computes the grand total spoken to the customer
- Ask for the wall-clock gap between 'placing your order' and the total
- Ask whether a rate change requires a vendor-side redeploy
- Ask to see a call where the delivery address is outside the restaurant's jurisdiction
- Ask how the vendor handles a state where the delivery fee is taxable
- Ask how alcohol items flow through the voice path
- Ask to compare the spoken total to the POS-committed total for the same call
- Ask who the vendor thinks the seller of record is, and why
Why this story is small but load-bearing
It is easy to look at the Denny's demo and notice the smooth upsell and the clean readback. Those are the features in the marketing copy. The quieter feature is that the agent takes a 2.4 second pause before quoting a dollar figure, and during that pause, a thing happened that determines whether the restaurant is sales-tax compliant at scale.
That pause is 2.4 seconds of PieLine refusing to invent a number, and instead waiting on the system that already knows what the number should be. It is a small architectural choice that decides whether a 100-location chain can trust the agent in all 50 states, whether a multi-state brand can keep its books clean at audit time, and whether a local operator can update a rate in the POS and have every phone order immediately reflect it, with zero vendor coupling.
The total spoken is $0. The architecture that produced it is the part worth evaluating.
See the 2.4-second POS round-trip happen on a live call.
A 15-minute demo walks through how PieLine posts your cart to Toast, Square, Clover, NCR Aloha, or Revel, lets the POS compute the tax, and reads the total back to the caller verbatim.
Frequently asked questions
Who actually computes sales tax on an AI phone order, the voice agent or the POS?
On PieLine the POS computes it. The agent gathers items and modifiers, posts the full cart to the POS's native order endpoint (Toast, Square, Clover, NCR Aloha, Revel), waits for the response, and reads back the total the POS returned. You can hear the seam on the public demo call at aiphoneordering.com: at 89.12 seconds the AI says 'Placing your order now.' At 91.52 seconds it says 'Done. Your total is $34.11.' The 2.4 second gap is the round-trip to the POS. The LLM never multiplies subtotal by a tax rate; the number spoken out loud is the number the POS already committed.
Why does it matter which side does the math?
Because restaurant sales tax is not a single rate. It varies by state (some states exempt grocery items, others tax prepared food differently), by local jurisdiction (city, county, and district surtaxes stack), by channel (pickup versus delivery versus dine-in have different treatments in many states), by menu category (hot food, cold food, beverages, alcohol each have their own rules in many places), and by whether the delivery fee is itself taxable. A POS configured once by a qualified operator handles all of that correctly. An LLM asked to 'compute tax' at the end of a call would need every one of those rules loaded into the prompt for every location. One does not scale and is forever one rule change behind the state; the other is already correct.
What does the customer actually hear on the call?
Exactly one number. 'Your total is $34.11.' The voice agent does not itemize tax verbally because no one wants that experience on the phone. But the $34.11 is the tax-inclusive grand total, identical to what the kitchen ticket and the customer's receipt will show. If the POS is set up correctly the breakdown is still preserved as discrete lines (subtotal, tax by rate, tip if applicable); the agent just collapses them into one spoken figure to keep the call short.
Does PieLine work in states where pickup and delivery have different tax treatment?
Yes, because PieLine does not decide. The POS does. States like Florida, New York, Illinois, and New Jersey all have different rules for whether the delivery fee is taxable, whether prepared food gets a reduced rate on pickup, and whether a bagged off-premises order is treated as grocery. Toast, Square, and Clover all have tax settings per service mode. PieLine tells the POS which service mode the call is for (pickup, curbside, or delivery with address) and the POS applies the rules it was configured with. The voice total reflects that.
What happens if the restaurant has multiple locations in different tax jurisdictions?
Each location has its own POS instance or its own location record inside the POS, each with its own tax configuration. When PieLine answers a call routed to the Palo Alto branch, it posts to the Palo Alto POS which applies the Palo Alto rate; when it answers a call routed to the San Jose branch, it posts to San Jose. The phone number the call came in on maps to a location ID at the PieLine routing layer. Multi-unit operators can have 50 different tax setups and the agent is correct at all 50 without a prompt change.
Can the AI agent lie about the total to make a sale?
Not in this architecture. The total it reads out is the value returned by the POS, not a value it generated. If the POS refused the order or returned an error, the agent cannot substitute a guess. That alignment is also what lets PieLine promise that the ticket the kitchen prints matches the total the customer heard. If you see the figure read aloud and the figure in the POS diverge, that is a configuration bug in the connector, not a hallucination in the voice.
What about tips, delivery fees, and service charges?
These are all POS-computed too. PieLine passes tip amount if the customer offered one verbally ('add a three dollar tip') but does not decide whether the tip is taxable; that is a POS setting that varies by state. Delivery fees on third-party pickup orders can be taxable or not depending on jurisdiction. The agent quotes the all-in number the POS returns. The itemization on the receipt and in QuickBooks or Restaurant365 is preserved as separate lines.
Does this architecture mean PieLine itself has no sales-tax liability?
PieLine is a software vendor, not a marketplace facilitator. It does not take money or hold the order; the POS processes payment via the restaurant's merchant account, the restaurant is the seller of record. Marketplace facilitator laws (the ones that cover DoorDash and Uber Eats) generally do not apply to the voice agent because the agent is a tool the restaurant uses, not an intermediate seller. Compare this to a third-party delivery app where the tax treatment depends on whether the state has classified the platform as the facilitator, which many states have. With PieLine the seller of record stays the restaurant, same as if a cashier had answered the phone.
How does PieLine handle alcohol, which has separate licensing and tax rules?
The POS is the enforcement point. Alcohol items in Toast, Square, or Clover are tagged as alcohol and trigger the restaurant's separate excise tax lines plus any age-verification workflow. PieLine does not bypass that. If alcohol is in the cart, the POS returns a total that includes the alcohol excise where required, and the agent reads that total out. For delivery, many states forbid voice-ordered alcohol without ID at dropoff; the restaurant's existing POS setting governs whether the order can be placed at all. The AI does not override the setting.
Can the agent provide a receipt with a tax breakdown?
Yes. The POS issues the receipt through its usual channel (email, SMS, printed at pickup). That receipt has the full tax breakdown as line items by rate. The voice agent's job ends at 'your total is $34.11 and your order will be ready for pickup at 12:45 AM,' and the POS's receipt fills in the details. Customers who want itemization get it from the receipt, not from making the agent talk for longer.
What if the state rule changes mid-year?
The restaurant updates the rate in the POS (Toast, Square, or Clover all surface this as a single admin setting per location). From the next order forward, the agent reads back the new tax-inclusive total automatically. Nothing in PieLine needs to be redeployed. A voice agent that computed tax internally would need a new prompt or a new table push for every location affected; the POS-as-source-of-truth model is why a single state rule change does not trigger 50 separate rollouts.
Where can I verify the 89.12 and 91.52 second timestamps?
Open src/components/voice-activity-data.ts in the PieLine repo (mediar-ai/pieline-phones on GitHub). Each caption has start and end fields in seconds. Search for 'Placing your order now' and 'Your total is' and you will see the exact offsets in the Deepgram multichannel transcription of public/audio/dennys-order.mp3. The 2.4 second gap is the wall-clock time between the order-submit message and the tax-inclusive total being spoken.
How did this page land for you?
React to reveal totals
Comments (••)
Leave a comment to see what others are saying.Public and anonymous. No signup.