The spreadsheet appears when billing events have nowhere intelligent to go. A failed payment, a missing tax location, an overdue invoice, and a customer asking for a copy all land in the same manual queue—even though they require different actions. An invoice exception agent creates a state machine around those events.
Let Stripe remain the billing system of record. Use verified events to open an exception case, let deterministic rules handle known states, use AI only to classify unstructured context or draft communication, and require approval for money-moving or account-changing actions.
Start with events, not inbox scraping
A reliable workflow begins with signed billing events such as payment failure, action required, invoice overdue, or invoice paid. The event creates or updates one exception record keyed to the invoice ID. Email can add context, but it should not be the primary source of billing truth.
Make handlers idempotent: receiving the same event twice must not create two cases or send two messages.
Use a small exception taxonomy
Retry scheduled, temporary failure, or customer action required.
Tax location, purchase-order reference, billing contact, or legal name absent.
Price, scope, credit, cancellation, or contract interpretation.
Billing platform and accounting or CRM records disagree.
The first two can often be operationally assisted. Commercial disputes belong to a person with account context. System mismatches should pause downstream changes until reconciliation.
Keep financial truth out of the language model
Decide states
- Invoice status
- Amount thresholds
- Retry eligibility
- Customer segment
Interpret context
- Classify reply intent
- Summarize account history
- Draft a clear message
- Extract a PO reference
Own judgment
- Credits and write-offs
- Contract disputes
- Cancellation exceptions
- High-value outreach
A useful payment-failure playbook
- Open the case.Attach invoice, customer, subscription, failure code, amount, attempt count, and next attempt.
- Check policy.Is a retry already scheduled? Is the decline hard? Is human authentication required?
- Choose the next action.Wait, request updated payment details, notify the account owner, or escalate.
- Draft communication.Use factual status and one clear next step; never speculate about the bank’s reason.
- Reconcile.Close only after a paid, voided, uncollectible, or approved resolved state.
Controls finance will actually trust
- Webhook verificationReject unsigned or replayed requests.
- IdempotencyOne external event cannot perform the same action twice.
- Action allowlistThe agent can only call explicitly approved operations.
- Money thresholdCredits, refunds, and write-offs always pause for approval.
- Daily reconciliationEvery open exception must match the current billing state.
Test the ugly states before production
Use a sandbox to simulate failed payments, required authentication, webhook retries, delayed events, out-of-order delivery, and a customer who pays while a review is open. The acceptance test is not “the happy path worked.” It is “replayed and conflicting events did not duplicate action or leave the case wrong.”
A hundred automated notes do not matter if unresolved exceptions still sit for three days.
Questions teams ask
Can the agent issue refunds?
Treat refunds and credits as high-risk tool calls. The agent may prepare the request and evidence, but a person should approve execution.
Why use webhooks instead of polling?
Billing events provide timely state changes. Polling can still be a reconciliation backstop, but it should not create competing actions.
What should close an exception?
A verified terminal state from the billing system or a documented human decision—not a positive-sounding customer email.
