Credits explained: how Smart Agents actually bills

Most AI tools bill by seat. Pay thirty euros per user per month, get unlimited use, and let the vendor eat the token costs. It is a clean model if you are a vendor who wants predictable monthly recurring revenue. It is a bad model for a Business Central tenant where usage is lumpy. A month-end close hits hard. A quiet August barely touches the agent. Most BC users are not daily AI users; they have a legitimate quarterly use case and you do not want to pay for the other eleven months.

We bill by credits because that matches reality. The formula is in the source: Smart Agent Credit Mgr. QUA, procedure estimate usage, lines 20 through 58. There is no hidden conversion table. Every customer can read it.

THE ARITHMETIC

A tenant gets 500 free credits on install. That is a one-time pool, not a monthly allowance, and it is enough to evaluate the product without a card on file. After that, you buy credits prepaid via Stripe, or, on AppSource SaaS deployments, through Marketplace metered billing. Both paths land in the same backend ledger and draw down the same balance.

Credits convert to tokens at a rate that depends on the model tier. The base rate at the Smart tier (our standard model in the backend) is one credit per ten thousand input tokens, or one credit per five thousand output tokens. Output tokens are twice as expensive as input tokens because output is twice as expensive everywhere in the industry; we did not invent that.

The rest is multipliers. The AL estimate usage procedure applies them like this:

Fast tier (our fastest model) multiplies the base estimate by 0.5

Smart tier (our standard model) multiplies by 1.0 (the baseline)

Expert tier (our advanced model) multiplies by 2.0

Premium tier (our premium model) multiplies by 4.0

The minimum charge per action is a small minimum credit charges. There is no per-request platform fee on top.

A WORKED EXAMPLE

The customer-statement workflow is a good benchmark because every BC shop runs it. A user opens the Smart Agent Chat page and types: "Send the September statement to customer 10000." The agent does roughly five things in sequence.

It reads the customer record and resolves the statement-to address. It pulls open entries from Cust. Ledger Entry, filtered to September. It formats a statement PDF using the BC report engine. It drafts an email to the customer's primary contact. It parks the draft in the user's outbox for review.

For a small customer with twenty-five open entries, the input to the model is roughly three thousand five hundred tokens (the agent is given the customer record, the open entries summary, and the user's request) and the output is roughly one thousand two hundred tokens (the email body, the action plan, and the structured JSON for the tool calls). On the Smart tier, that is 3,500 / 10,000 = 0.35 input credits, plus 1,200 / 5,000 = 0.24 output credits. Total: 0.59 credits, or about six tenths of a euro cent rounded. Run a hundred of those at month-end and you have spent under a euro.

A more expensive example: a Premium-tier cashflow forecast that reads three months of posted G/L and builds a reasoned thirty-day projection. Input: twelve thousand tokens. Output: three thousand five hundred tokens. Base estimate before the multiplier: 12,000 / 10,000 + 3,500 / 5,000 = 1.9 credits. Apply the Premium multiplier of 4.0 and you land at 7.6 credits, or under eight cents. Worth it for a forecast nobody had to assemble by hand.

The estimate is conservative. The reservation pattern (procedures reserve credits, confirm usage, release credits in the same codeunit) holds the estimated amount before the call and confirms the actual amount after. If the model returned fewer tokens than expected, the difference is released back to the balance. You never pay for tokens you did not use.

WHY WE EXPOSE THE TIERS

Most platforms hide the model. Usage feels magical until the bill arrives. We exposed the tiers because the tier is the cost knob you actually want as an admin. A routine "who are my top customers" question does not need the Premium model. A cashflow forecast does. The default tier is set on each agent in the Smart Agent table (, field AI Model Type), and admins can override per template or per individual custom agent.

The single biggest cost-control move we see in pilots is to leave Smart as the tenant default and only promote agents to Expert or Premium when the cheaper tier produces visibly worse answers. That one decision typically halves the monthly credit burn relative to a tenant that defaults everything to Premium because it sounds nicer.

NO MINIMUM SEATS

You do not buy Smart Agents per user. You register BC users into the extension via the Smart Agent User table and they draw from the same tenant-level credit pool. A tenant with eighty BC users and three power users running most of the queries pays for what those three actually consume. The other seventy-seven cost nothing until they send a message.

This is what kills seat-licensed AI in the BC world. Most BC users are casual AI users. Paying thirty euros per user per month for eighty seats over a year is more than twenty-eight thousand euros, and the vast majority of that is for messages nobody sent. Credit billing makes the bill a function of work done, not seats provisioned.

WATCHING THE METER

Users see their own balance and recent message-level cost on the Smart Agents Credits page. Admins see tenant-level usage, per-user burn, and per-agent cost on the same page with administrator filters. The low-credit warning is configurable on the Smart Agent Setup table (, field Low Credit Warning), and the codeunit fires a notification through the BC notification framework when the balance drops below it.

For tenants on AppSource Marketplace metering, the same usage rolls into Microsoft's metered billing API and the customer pays through their existing CSP relationship. Prepaid credits do not expire on the prepaid path: the budget you fund in January is the budget you spend in December.

WHAT HAPPENS WHEN CREDITS RUN OUT

The behaviour at zero is documented and predictable. The low-credit check procedure in the credit management module fires a BC notification when the balance drops below the configured Low Credit Warning threshold (default 50 credits). The notification appears on the next chat-message submit and persists across sessions until the balance is topped up.

If the balance hits zero, the next message attempt fails at the reservation step: the reserve credits procedure returns an empty reservation ID and the chat engine refuses to submit the message. The user sees a clear error in the BC client, not a silent timeout. Admins can top up via the Buy Credits page which calls the checkout procedure to open a Stripe checkout in the browser, or they can wait for the next AppSource metered-billing cycle to add capacity automatically. Existing reservations already in flight are not cancelled when the balance hits zero; they confirm normally on completion.

CREDIT DISPUTES

The dispute handling procedure (lines 129 to 138 of the credit management module) lets users flag a bad or incomplete response and request a credit adjustment. The dispute lands in the QUALIA backend ticket queue and is reviewed by a human within two business days; refunds are credited back to the same balance. We document this because we expect to use it; not every model response is good. The intent is to make it cheap and frictionless to call out a bad answer, because a vendor that hides bad answers ends up with a bad product.

WHY NOT SUBSCRIPTIONS

We occasionally get asked why we do not also offer a subscription tier. The honest answer is that the math does not work for the BC user base. A subscription that covers "unlimited use" has to price for the heaviest 5% of users, and the median user pays for capacity they do not consume. A subscription that caps usage has to define the cap in some unit (messages? tokens? actions?) and we are back to credits with worse names. We chose the unit that maps to the underlying cost (tokens), exposed the multipliers that decide that cost (model tiers), and let the customer make their own pricing decisions per agent.

Subscription billing is supported in the codeunit (the Smart Agent Billing Mode QUA enum has both Prepaid and Subscription values) for tenants that explicitly request it as part of an enterprise CSP arrangement, but it is not the default and we do not market it. The credit model is honest about the underlying economics, and honest billing tends to win audits.

If you want to verify any of this against the source, the file paths are above. See /docs/getting-started for setup, the related blog post on picking the right model tier for the trade-off conversation, and the FAQ entry on what happens when credits run out.