Fini for billing and invoices

Fini resolves billing and invoice requests by reading each customer’s live billing record through User Attributes and Actions, so replies quote the real balance, invoice number, payment status, and next charge date instead of generic policy text. Routine work (resending an invoice, explaining a charge, updating billing details) runs as a deterministic Intent Rule, while anything that moves money back to the customer or contests a charge goes to your team through Reply Rules and escalation. This page shows how to map a billing queue onto Fini’s building blocks. It is a pattern to adapt, not a fixed recipe: your billing system, refund policy, and approval thresholds decide the exact tree.

What Fini handles and what it hands to your team

Most billing volume is lookups and small, reversible changes. Those are safe to automate end to end. Requests that need judgment, touch payment credentials, or create a financial liability stay with people.

Request	Who handles it	How
”Can you send me a copy of my invoice?”	Fini	A Tool node calls your `Resend Invoice` Action and the Reply confirms where it was sent.
”What is this charge?” / “Why is my bill higher this month?”	Fini	A lookup Action returns the invoice line items; the Reply explains them with real amounts.
”When is my next payment?” / “What’s my balance?”	Fini	Read from the billing attribute on every message, no Action needed.
”My payment failed”	Fini	Explains the failure reason from your billing data and links to your self-serve payment page. Fini never collects card or bank details in chat.
”Change the billing email” / “Add our VAT or tax ID”	Fini	A Form collects the typed values, an Action writes them, the Reply confirms.
Proration, tax, and refund policy questions	Fini	Answered from your Knowledge articles.
Refund requests	Your team (or Fini under a threshold you set)	Fini looks up eligibility and drafts the reply; a Reply Rules Internal Comment card posts it as an internal note for approval. See Fini for refunds and returns.
Charge disputes, chargeback threats, suspected fraud	Your team	Escalated through the Planning Prompt’s Escalation Topics before any rule runs. See Fini for disputes and chargebacks.
Payment plans, hardship, fee waivers, collections	Your team	Escalated; these are policy exceptions, not workflows.

Start with the lookup intents. They carry the most volume, have no side effects, and give you a clean read on how well the billing attribute and tags work before you put any write Action behind the agent.

How it works in Fini

A billing setup uses the same four pieces as every Fini workflow: an attribute for context, Actions for work, an Intent Rule for orchestration, and Reply Rules for overrides. Guardrails and Knowledge sit around them.

Piece	What it does for billing	Where
Tags	A Rulebook-enabled group (for example `Billing Intent`) classifies each conversation as `invoice_request`, `charge_question`, `payment_failed`, `billing_details_change`, `refund_request`, or `other`.	Tags
User Attributes	A `Billing Account` attribute looks up the customer in your billing system on every message and exposes `billing_customer_id`, `plan`, `balance_due`, `next_charge_date`, `payment_status`, `last_failure_reason`, and `recent_invoices`.	Attributes
Actions	`Get Invoice Details` (read-only), `Resend Invoice`, and `Update Billing Details`, each with typed inputs and outputs.	Actions
Intent Rule	A Fallback-rooted tree with one branch per billing intent, so one rule covers the whole billing queue.	Intent Rules
Reply Rules	Internal Comment for refund requests and high-value accounts, No Reply when a human is already on the conversation.	Reply Rules
Business Rules	Create the helpdesk ticket when a widget billing conversation escalates.	Business Rules
Guardrails	Keep internal billing IDs out of replies and restrict links to your billing domains.	Guardrails
Knowledge	Billing policy articles (proration, taxes, refund windows, accepted payment methods) for every question the tree doesn’t own.	Articles

The billing attribute

Configure one attribute with a Data Collection Step that calls your billing system by the customer’s email or account ID. Toggle each collected field deliberately:

Field	Use in Rulebooks	Visible to AI	Why
`billing_customer_id`	✓		Checks verify the customer is identified; Tool inputs bind to it. Never quoted to the customer.
`payment_status`	✓	✓	Checks branch on `past_due`; the agent can tell the customer their status.
`last_failure_reason`		✓	Lets the agent explain a declined payment in plain language.
`balance_due`, `next_charge_date`, `plan`	✓	✓	Answers “what do I owe and when” without an Action call.
`recent_invoices`		✓	Lets the agent ask “the March invoice or the April one?” when the customer doesn’t name one.

The same pattern is walked through field by field in End-to-end: order status and changes, where recent_orders plays the role recent_invoices plays here.

Example behavior tree

Example to adapt. The tree below shows the shape of a billing rule. Tag values, field names, and Action names are placeholders; replace them with the ones in your workspace.

Fallback  (root: one branch per billing intent)
├── Steps  (Invoice copy)
│   ├── Check: Billing Intent Equals invoice_request
│   ├── Check: billing_customer_id Is Not Null
│   ├── Read:  extract `invoice_id` (String) from the message and recent_invoices
│   ├── Tool:  Resend Invoice
│   │     in:  billing_customer_id, invoice_id
│   │     out: invoice_number, sent_to
│   └── Reply: confirm invoice ${invoice_number} was sent to ${sent_to}
├── Steps  (Charge explanation)
│   ├── Check: Billing Intent Equals charge_question
│   ├── Read:  extract `invoice_id` (String)
│   ├── Tool:  Get Invoice Details
│   │     in:  billing_customer_id, invoice_id
│   │     out: line_items, total, proration_note
│   └── Reply: explain the line items and ${total}; mention ${proration_note} if present
├── Steps  (Failed payment)
│   ├── Check: Billing Intent Equals payment_failed
│   ├── Check: payment_status Equals past_due
│   └── Reply: explain ${last_failure_reason}; share the self-serve payment page link
├── Steps  (Billing details change)
│   ├── Check: Billing Intent Equals billing_details_change
│   ├── Form:  billing_email, company_name, tax_id
│   ├── Tool:  Update Billing Details
│   │     in:  billing_customer_id, billing_email, company_name, tax_id
│   │     out: updated_at
│   └── Reply: confirm the new billing details apply from the next invoice
└── Reply: ask which billing request the customer means

How this runs: the root Fallback tries each branch in order, and each branch opens with an intent Check, so only the branch matching the conversation’s Billing Intent tag runs. If the customer isn’t identified, the billing_customer_id Check fails and the branch stops before any Action fires. The last child asks a clarifying question when no branch applies.

Failed payments end in a link, not a form. Point customers to your billing portal to update a card or bank account. Don’t build a Form or Read that collects payment credentials in the conversation; payment details belong in your payment provider’s hosted page. See PCI DSS for how Fini approaches cardholder data.

The Form in the billing-details branch renders in the Widget. On email channels, replace it with Reads in sequence, as described in the channel notes of End-to-end: card replacement.

Refunds under a threshold

If you want Fini to issue small refunds itself, add a refund branch that chains a read-only eligibility Tool before the refund Tool, and gate the write on the eligibility output (for example refund_amount Less Than or Equal To 50). The pattern is in Rulebook → Chaining Tools. Everything above the threshold falls through to the internal-note path below.

Guardrails and escalation

Billing mistakes are visible and expensive, so layer the controls:

Escalate disputes before any rule runs

In the Planning Prompt, add Escalation Topics for charge disputes, chargeback or “I’ll contact my bank” language, suspected fraud on an invoice, collections, and legal threats. The planner routes these to a human and skips the billing rule entirely. See Prompts → Controlling when the agent escalates.

Hold refunds for review with Internal Comment

On Rulebook → Reply Rules, enable the Internal Comment card with Billing Intent Equals refund_request. Add an alternative group for high-value accounts, for example plan Equals enterprise. The agent still looks up eligibility and drafts the reply; your team sends it.

Stay silent when a human owns the ticket

Enable No Reply with Human Agent Assigned Equals True so the agent never talks over a billing specialist. No Reply wins over Internal Comment, which wins over Direct Reply.

Add reply checks

On Guardrails, add Confidential attributes for billing_customer_id and any internal risk or collections flags, a URL allowlist with your app and billing portal domains so the agent only links to real payment pages, and Banned terms for phrases your finance team never wants promised (for example “refund guaranteed”).

Route escalations to the billing queue

For widget conversations, a Business Rule creates the ticket in your helpdesk on escalation. For native tickets, map the billing tags to a billing team with Agent groups.

Reply Rules gate only the final reply. If a refund Tool sits in the tree, the refund still executes when Internal Comment matches; only the confirmation is held. Keep write Actions that need approval out of the tree, or split the rule in two as described under “Holding the destructive Action itself” in End-to-end: card replacement.

What you need

What	Why	Where
A billing API	Read endpoints for the customer and invoices, plus write endpoints for resending invoices and updating billing details. Follow the API contract for endpoints you build.	Your billing system
A credential scoped to those endpoints	The Data Steps call your API with the credential in their Headers. Issue a dedicated key that can read invoices and perform only the writes the agent needs.	Your billing system
A self-serve billing page	The destination for payment-method updates and anything the agent should not do in chat.	Your app
A Rulebook-enabled tag group	The intent Checks in each branch read it. Turn on Tag Group available in Rulebooks and write AI Instructions that separate `charge_question` from `refund_request`.	Tags
Billing policy articles	The fallback for every question the rule doesn’t own.	Articles
Sandbox customers	Test invoices and a test payment failure to verify each branch without touching real accounts.	Your billing system

What to measure

Open Analytics after the rule has run for a week:

Intent rule breakdown. The billing rule’s AI Resolve Rate, Escalated Rate, and Volume. A low resolve rate with a high escalated rate usually means a missing Action or a Check gated too tightly.
Tags filter. Filter to each Billing Intent value to see which billing requests drive volume and which escalate.
Escalation reasons. Missing API Access points at a billing request you haven’t wired an Action for; API or System Failure points at your billing API; Missing Knowledge points at a policy article to write.
Conversation status. Count Resolved by AI, not deflection. Deflection rate includes conversations still Waiting for Customer, such as a customer who was sent to the billing portal and never came back.

Before each change to the rule, run a Test Suite set with the Tool use correctness judge, and run it with Simulate rule execution or point the Actions at sandbox endpoints: Test Suite runs don’t dry-run your Actions, and Execute live actions calls your real APIs.

End-to-end: order status and changes

The closest walkthrough: a Fallback-rooted rule that handles several related intents with a shared lookup Action.

Intent Rules

Node types, chaining Tools, Forms, and testing a rule.

Reply Rules

Internal Comment and No Reply conditions, and the priority order between them.

Guardrails

Confidential attributes, URL allowlist, and banned terms.

Attributes

Data Collection Steps and the Use in Rulebooks and Visible to AI switches.

Guide: AI support for subscription billing questions

The usefini.com guide to automating subscription billing questions.

Use cases

Walkthroughs

Industry setup

How-tos

Fini for billing and invoices

What Fini handles and what it hands to your team

How it works in Fini

The billing attribute

Example behavior tree

Refunds under a threshold

Guardrails and escalation

What you need

What to measure

End-to-end: order status and changes

Intent Rules

Reply Rules

Guardrails

Attributes

Guide: AI support for subscription billing questions

​What Fini handles and what it hands to your team

​How it works in Fini

​The billing attribute

​Example behavior tree

​Refunds under a threshold

​Guardrails and escalation

​What you need

​What to measure

​Related

End-to-end: order status and changes

Intent Rules

Reply Rules

Guardrails

Attributes

Guide: AI support for subscription billing questions

What Fini handles and what it hands to your team

How it works in Fini

The billing attribute

Example behavior tree

Refunds under a threshold

Guardrails and escalation

What you need

What to measure

Related