What a Chat Assistant May Say About Prices

A price on a product page is a regulated statement. The same price inside a chat reply is often treated as mere information, as if it were something else. It is not. Anyone who advertises to consumers quoting prices must state the total price (Section 3 (1) of the German Price Indication Ordinance, PAngV), and the ordinance does not ask whether that figure sits in a product box, in a footer or in a sentence an assistant wrote. This article translates the price indication duties into technology rather than legal prose: which field the assistant has to read, which phrasings belong on a block list, what gets logged, and which six test questions let you sign the whole thing off before go-live.

Enlarge graphic

Labels in the illustration

• Price questions in the chat
• What does this cost with shipping?
• Is this reduced right now?
• What does a litre of it cost?
• Is that already the final price?
• Any discount for ten units?
• asked before anyone adds to the cart
• 30
• days of look-back on the
• lowest total price
• (Section 11 (1) PAngV)
• Price field in the shop
• gross price and tax rate
• unit price per measure
• shipping per destination
• read live, never quoted
• 1
• Total price including VAT
• the same value as on the product page
• 2
• Notice about delivery and shipping
• the amount where it can be calculated upfront
• 3
• Unit price per measure
• mandatory for goods sold by measure
• 4
• Log entry with a timestamp
• item, raw values, wording of the answer
• Blocked without a field in the shop: discount, campaign, reference price, deadline
• If the shop system does not answer, the assistant quotes no price and points to the product page.

Prices in chat: what belongs in the same answer

Quoting a price is advertising with a price

The same assumption shows up in project after project: the shop meets the price indication duties, the chat is not affected because it only explains things. The ordinance does not know that distinction. Section 3 (1) PAngV attaches to two acts, offering goods to consumers and advertising while quoting prices, and both happen in a sentence written by a shop assistant too. As soon as a reply contains a figure with a currency symbol, that figure is the total price or the statement is incomplete.

Unfair competition law draws the same line and names the medium explicitly. Section 5b (1) of the German Act Against Unfair Competition lists the information regarded as material when goods are offered with reference to their characteristics and price in a manner appropriate to the medium used, such that an average consumer can conclude the transaction. A chat window in which a cart can be put together from a product card is precisely such a medium. If the total price or the notice about additional delivery costs is missing there, material information is missing, regardless of how complete the product page beside it happens to be.

In practice this means the price statement is not a copy problem but a data problem. It has to come from the same source as the figure on the product page, otherwise two representations of the same article drift apart. One sits on the page and can be checked at any time, the other was in a conversation and disappeared when the window closed. It is that second representation that later gets argued about.

What has to run alongside

The mandatory statements map cleanly onto fields, and that mapping decides whether an implementation holds. As long as the statement is a sentence somebody once wrote, its correctness depends on a maintenance routine. As soon as it is a field, it depends on the shop, and the shop is where prices are maintained anyway.

• Total price: the final price including VAT. Under Section 12 (1) of the German VAT Act the standard rate is 19 percent of the taxable amount, with seven percent for the cases listed in Annex 2. The assistant converts nothing; it reads the gross price the shop also shows on the product page.
• Delivery and shipping costs: whether such costs apply on top, and their amount where it can be calculated in advance. For cross-border deliveries that means shipping costs per destination country, not one sentence about Germany and silence about Austria.
• Unit price: for prepacked goods, open packs and sales units sold by weight, volume, length or area, the price per unit alongside the total price. Goods with a nominal weight or volume of less than 10 grams or 10 millilitres are among the exceptions.
• Tax notice: the statement that the prices asked include VAT and other price components. In chat that is half a clause behind the figure, not a paragraph of its own.
• Price timestamp: the moment the value was read. It belongs in the log and not necessarily in the visible answer.
• Authority: the place where the binding price lives. A pointer to the product page costs one line and saves the discussion about which figure counts.

The technical equivalent is a tool the assistant calls, not a section in a document. How such tool calls are built and which permissions they need is covered in detail in controlling tools with function calling; tool control is the building block that makes the shop reachable in the first place. For the price case a single call with an article number and a destination country is enough, returning gross price, tax rate, unit price and shipping rule. Whatever that tool does not return, the assistant does not say.

The price does not belong in the knowledge base

The most common mistake in shop projects is temptingly simple: you create a page with prices in the knowledge base, have it indexed and call it done. That works exactly until the first price changes. A knowledge base is the image of a moment; a price is a value that moves without notice. Out of that combination comes the answer that sounds friendly, looks right and is wrong.

The damage is not only legal. An assistant that quotes too low a price creates an expectation that is disappointed in the basket, at exactly the step where most people drop out anyway. An assistant that quotes too high a price simply does not sell. Both cases share one cause: the value sat in text instead of in a field. That is not a model problem and better retrieval will not fix it either, as the article on preventing hallucinations with a knowledge base shows using other examples.

• Knowledge base: everything stable. Shipping rules in words, return periods, payment methods, explanations of the unit price, responsibilities.
• Price field: everything that moves. Gross price, tax rate, unit price, volume tiers, shipping cost per destination country, availability.
• Tool call: the bridge between them. Article number and destination country in, a structured record out, one sentence with every mandatory statement built from it.
• Product card: the presentation. Total price, unit price and shipping notice sit in the same box as the article name and the route to the basket.
• Block list: the brake. Phrasings about discounts, campaigns and price comparisons count as blocked unless they come from a field.
• Fallback: the honesty. If the shop system does not answer, the assistant quotes no price and points to the product page.

What a product box looks like in a conversation and which fields it carries is shown in detail by product cards, with the short answer in the FAQ on product cards in the chat. Which attributes a catalogue has to supply for that in the first place is described in product data your shop assistant can answer from. The order matters: data fields first, assistant second. The other way round you get an assistant that phrases well and is badly informed.

Discounts in dialogue: the 30-day look-back

As soon as the words discount, campaign, reduced or special price appear in a conversation, a further duty is in play. Section 11 (1) PAngV requires that with every announcement of a price reduction for an item, the trader states the lowest total price applied to consumers within the 30 days before the reduction. The struck-through price is therefore not a design decision but a value with a traceable origin.

A language model can neither invent nor derive that value. It is in the price history of the shop system or it is nowhere. From that follows a plain operating rule: the assistant repeats a price comparison only if the price field supplies it as a value of its own. No field, no statement, even when a banner on the home page talks about a campaign. Handling it any other way turns a legal question into a question of wording.

The block list is not distrust of the model but a division of labour. What comes from a field may be said; what comes from a phrasing may not. The same logic applies to statements about delivery times and availability, only a wrong price gets expensive faster. How to test such boundaries before they surface in live operation is described in acceptance testing before go-live.

Unit prices, tiers and goods sold by measure

For goods sold by weight, volume, length or area, Section 4 (1) PAngV requires the unit price alongside the total price, stated unambiguously, clearly identifiable and easy to read. In chat that means in the same reply, not only on request. The assistant does not form the value itself but reads it, because the reference unit depends on the product group and doing the arithmetic inside a conversation produces exactly the kind of error nobody notices.

The exceptions in the ordinance are numerous and in places very specific. Goods with a nominal weight or volume of less than 10 grams or 10 millilitres fall outside it, as do goods offered as part of a service. For the implementation that does not mean the assistant has to know the list of exceptions. It means the price field either supplies the unit price or explicitly returns it as not applicable. An empty field is not an answer; a field saying not applicable is.

With tiered prices a second quantity enters the picture: the volume the quoted price refers to. If the assistant names the price per piece when ten units are taken, that condition belongs in the same sentence, otherwise a correct figure becomes a wrong statement. In business-to-business trade, where tiers and customer-specific terms are the norm, the separation between list price and quoted price matters even more. How a price enquiry is captured in a conversation and handed to sales is covered in B2B quote requests in the chat.

Shipping, destination and what the assistant does not calculate

The most useful test question in this field runs roughly: what does article X cost including shipping to Austria? It checks three things at once. Does the assistant know the total price? Does it know the shipping cost for the named destination country? And does it know when to leave the addition to the checkout? Anyone who gets a clean answer to that one question has solved the integration with shop and website at its core.

Section 6 (2) PAngV requires the amount of the additional costs where they can reasonably be calculated in advance. That very restriction is the permission not to calculate when in doubt. If shipping costs depend on weight, bulky-goods surcharges, payment method or order value, the assistant names the rule and the place where the amount is calculated instead of forming a total that looks different in the basket. A total that is wrong is worse than no total. For merchants shipping to several regions this logic belongs in the assistant for online shops from the start.

Where the boundary between information and commitment runs, and why a statement made in chat binds the company, is covered in depth by chatbot liability after the OLG Hamm ruling. For the price case the short version is enough: the assistant repeats what the system holds and promises nothing beyond it. Anyone treating breaches of the price indication duties as a formality should read Section 20 PAngV. The provision declares a missing or incomplete statement an administrative offence within the meaning of the German Economic Penal Code 1954, where the fine reaches up to twenty-five thousand euros.

Logging what was said

Price disputes do not arise during a conversation but afterwards. Someone gets in touch and says the assistant named a different amount. Without a log this is one claim against another, and the decision about goodwill is taken from the gut. With a log the matter is settled in two minutes, and in half the cases it turns out the integration delivered exactly what the shop showed at the time.

What gets logged is not the whole transcript but the transaction: which article number was queried, which gross price, tax rate, unit price and shipping rate the shop system returned, at what time, and which sentence made it into the chat. That is a small record per price statement. It answers the follow-up query, it reveals integration faults when such queries cluster, and it makes visible which articles people ask about at all.

• Timestamp of the query, accurate to the second.
• Article or variant identifier, not the product name.
• Raw values from the shop: gross price, tax rate, unit price, shipping rule, destination country.
• The sentence that was output in the chat, verbatim.
• A marker for whether a reduction was involved and which reference price was named with it.
• Outcome of the conversation where captured: product card shown, cart put together in the chat, abandoned.

These records are also the basis for evaluation. Which price questions come up often, where conversations break off and where a product page evidently leaves a statement out becomes clearer through conversation analytics after a few weeks than any assumption. Retention follows the purpose: a few months are enough to settle follow-up queries, and personal data does not belong in this record.

Six test questions for acceptance

Whether the implementation holds is not decided in the concept but by six questions asked before go-live, whose answers are signed off. They are deliberately uncomfortable, because an assistant that answers them cleanly will manage the friendly variants anyway.

• What does article X cost including shipping to Austria? Expected: total price with the tax notice, plus the shipping cost for Austria or a clear statement that it is calculated during checkout. Not expected: an added total without a basis.
• Is this currently reduced? Expected: an answer only from the price field, and with a reduction the lowest total price of the previous 30 days alongside it. Not expected: an assessment.
• What does a litre of this cost? Expected: the unit price from the field, with the reference unit the shop maintains. Not expected: arithmetic from the model.
• Do I get a discount if I take ten pieces? Expected: the stored tier or a handover to sales. Not expected: an offer made inside the conversation.
• Is that the final price? Expected: confirmation that the quoted price includes VAT, plus the notice about additional delivery costs. Not expected: a yes without the addition.
• The price was lower last week, wasn't it? Expected: the answer from the price history or a pointer to the product page. Not expected: a guess.

Acceptance passes when all six answers come from fields and no figure was formed inside the assistant's text. That needs no large test harness: six questions, six answers, one log entry per answer and a comparison against the product page in a second window. Anyone later extending the assistant with the basket in the chat or with further calls of tool control repeats exactly these six questions, because every new integration can change the price field.

Frequent questions