Voice AI invoice assistant: what works on web and Android

TL;DR: A voice AI invoice assistant should do more than transcribe speech. It needs microphone access, reliable speech recognition, an assistant that can call tools, and a safe apply flow so revenue questions are answered from real data and invoice changes actually save. Inbill supports voice on the website and Android app, with native Android speech recognition, browser microphone permissions, live AI conversations, and review-before-apply safeguards for writes.

What a voice invoice assistant actually needs

Voice invoicing has four moving parts. The browser or app must capture the microphone. Speech-to-text must turn audio into text accurately enough for money fields. The AI assistant must understand whether the user is asking a question or requesting a change. Finally, the app must execute tools against the database and return the result to the assistant so it can say "done" only after the work really happened.

This is why simple chatbot wrappers fail. An assistant can talk convincingly and still fail to use tools if the live session did not accept the tool schema, if microphone frames start before setup completes, or if the app never sends a function response back. Inbilling is not general chat: "What did I earn this month?" must call a revenue tool, and "create an invoice" must create a draft row.

Website microphone permissions

On the web, microphone access only works in a secure context: HTTPS or localhost. The browser prompts the user the first time a page calls getUserMedia. If the user blocks the prompt, the app cannot override that decision; the user must re-enable the microphone from browser site settings. Chrome, Edge, Safari, and modern Android browsers all support this flow, but private browsing modes and embedded browsers can be stricter.

Inbill checks these requirements before starting Live mode. If the browser does not expose microphone access, WebSocket, or Web Audio, it shows a specific error instead of a vague "Live mode unavailable." That matters for support because microphone failures are usually permission or browser-policy issues, not AI-provider issues.

Why Android WebView needs a native speech path

Android WebView is not the same as Chrome. The Web Speech API may appear to exist but fail to produce results inside many Capacitor and Cordova apps. For native Android apps, the reliable free path is a Capacitor speech recognition plugin that bridges to Android's built-in SpeechRecognizer. That gives live partial transcripts without paying for every spoken minute.

Inbill uses a layered approach: native Android speech recognition first, browser speech or browser microphone paths on the website, and server-side transcription fallback only when a free device path is unavailable. This keeps the mobile app fast and affordable while still making the website usable from a desktop browser.

Live conversations still need tool calls

Real-time AI assistants can hold a spoken conversation, but conversation alone is not enough for invoicing. The assistant must receive function declarations, decide when to call them, wait for the app's tool response, and then speak the result. If any one of those boundaries breaks, the assistant may say "let me retry" while no database work happens.

Inbill treats this as an engineering boundary, not a prompt-writing problem. Read tools such as revenue, pending invoices, overdue invoices, and payment history run server-side under the signed-in user's permissions. Low-risk writes such as create client, create invoice, mark paid, and record payment can auto-apply. High-risk actions such as delete and send email require a confirmation card or spoken yes after the assistant asks clearly.

Why review-before-apply matters

Invoices are legal and financial documents. A voice assistant should never silently send a wrong amount, wrong currency, or wrong client. The right pattern is fast drafting plus visible confirmation. For low-risk draft creation, the assistant can create the draft and tell the user the invoice number. For destructive or external actions, the assistant should pause and ask for confirmation.

This is the same reason Inbill separates read questions from write actions. "How many pending invoices do I have?" should never create anything. "Create an invoice for Acme" should not merely describe how to create one. The voice interface is successful only when the underlying tool result matches the user's intent.

How to debug voice AI in production

Production voice bugs usually hide across layers: browser permission, WebSocket setup, tool schema, database row-level security, or the function-response protocol. Good diagnostics log each boundary without exposing secrets or full invoice data. Inbill's Android app forwards JavaScript logs to logcat under the InbillJS tag and also includes a Live diagnostics copy button so testers can send recent tool-call events without installing developer tools.

The most useful events are simple: setup sent, setup complete, mic granted, tool call received, tool decision, read ok, write auto-applied, tool response sent, and upstream closed. If "revenue this month" fails, those events tell us whether the assistant never called the tool, the tool failed, or the response never got back to the live session.