An AI assistant reviewing an invoice can read the document, flag a discrepancy and recommend payment. Paying the invoice is a separate decision: an employee has to explicitly approve that specific payment. An employee's authority to approve payments is not evidence that they approved this one.
Who actually approves the invoice?
Take a hypothetical invoice workflow. An employee asks an assistant to review a supplier invoice and suggest the next action. The assistant retrieves the invoice through an application-provided tool and recommends approval. The recommendation approves nothing. The employee opens the invoice on the application's approval screen, checks the supplier, amount and payment details shown there, and explicitly approves them.
There is a useful detail in Anthropic's tool-use documentation: for a client tool, Claude responds with a tool_use block naming the requested operation. The application executes the tool and sends a tool_result back. A tool request therefore gives the application a place to reject an unauthorized action before it reaches the accounting system. This execution pattern applies to client tools; Anthropic-hosted server tools execute on Anthropic's infrastructure.
For this workflow, we would keep invoice retrieval separate from approval, and the assistant would have no tool that approves an invoice or releases a payment. The approval handler would accept only an approval the signed-in employee submitted from the application's own screen. That record would be bound to the invoice ID and to every material payment detail the employee saw: the amount, currency, payee and destination bank account details. The handler would also check the employee's authority and the invoice's current status each time.
If any of those details changes after approval, the earlier approval no longer covers the invoice and the employee has to approve the new details. A confirmed: true value or similar flag in the model's output is text the model produced and cannot serve as proof of approval. Describing a permission rule in a prompt does not enforce that rule in the accounting database. A rejected request should leave the invoice unchanged and tell the employee why approval was refused.
When the accounting connection times out
Suppose the employee approves the invoice, but the accounting connection times out before returning a result. Repeating the approval immediately could duplicate an action that already succeeded. Leaving the employee with a reassuring chat response would conceal the uncertainty.
We would record the attempted operation against the invoice and show an unresolved status in the approval screen. Support should see the attempted action and connection error on that invoice. Before allowing a retry, the application should check whether the accounting system recorded the approval. Where the accounting API supports an idempotency key, reusing that key gives the retry a way to identify the original operation. Test that behavior with an interrupted connection. Separate tests should cover unauthorized employees and invoices already approved.
The credential's scope
IKRC team members hold the Claude Certified Architect - Professional credential, issued by Anthropic, and apply it in our AI implementation work. Anthropic's credential description covers enterprise architecture, integration, system optimization, and deployment governance. Earning it requires passing a proctored exam. The credential belongs to the people who earned it; it is not a certification of an IKRC application. An invoice workflow still needs testing against the rules of the business using it.
Starting with an existing approval screen
A reasonable first version reads invoices and drafts recommendations while staff keep the existing approval button. We would trace each recommendation through the accounting integration to the point where an employee approves it, confirm that the approval handler accepts only that recorded approval, and test it against the screen staff already use. Payment of an approved invoice would still go through the controls the business already has.