Skip to content
Queue

Charged twice for the March invoice

Priya RamanProOrder $49.00Opened Aug 10, 2026, 1:01 PM

AI decision summary

Produced by seeded

Two identical 49.00 USD charges are reported against a single March invoice, which billing can settle from the payment log.

AI prepared this decision. A human authorizes the action. Nothing below has happened yet.

Status

Executed

Risk

LOW risk

Confidence

0.84/ 1.00

Severity

Medium
Workflow position: Step 7 of 7

Proposed action

Produced by seeded
REPLY

Send the drafted reply to the customer.

The duplicate is visible in the payment log and self-resolves, so an explanation is the complete answer. No refund is proposed because nothing was captured.

Risk computed from

Severity
MEDIUM
Action
Send reply
Customer tier
Pro
Safe to send
yes

Proposed response

Produced by seeded

Hi Priya, Thanks for flagging this, and for the detail on the dates. I can see two authorisations of 49.00 USD dated 3 March against your account. One is the March subscription charge; the second is a duplicate raised when the first payment attempt was retried. Only one invoice was issued, which is why the portal shows a single entry. I have asked billing to void the duplicate authorisation. It will drop off your statement within three to five business days without any action from you, and no credit note is needed because the second charge was never captured as revenue. If it is still showing after five business days, reply here and I will chase it directly. Best regards, Support

Drafted text. Nothing is sent until this is approved.

Evidence and decision factors

Produced by seeded

Customer message

Hi, our finance team flagged two charges from you on the same day, both for 49.00 USD, on the 3rd of March. The invoice portal only shows one invoice for that period. Can you confirm whether we were billed twice, and if so which invoice the second charge belongs to? We need this resolved before we close the month.

Category
Billing
Routed to
billing-tier1

Evidence from the ticket

  • two charges from you on the same day, both for 49.00 USD
  • The invoice portal only shows one invoice for that period

Each quote is matched against the message above before it is shown.

Decision factors

  • Two identical charges are reported against a single invoice record, which is a reconciliation question rather than a fault.
  • The customer states a month-close deadline, so it is time-bound but not an outage.
  • Tier 1 billing can read the payment log and answer without an engineering handoff.

Previous tickets

Settled tickets that share this customer or this category, matched on those fields and ordered by recency. Not a similarity score.

Operational rules that apply

  • A duplicate authorisation is not a duplicate charge

    Billing operations handbook, section 2.1

    A retried payment attempt can leave a second authorisation against an account without a second capture. Read the payment log before describing it to a customer: an uncaptured authorisation drops off without a credit note, and offering one implies money moved that never did.

  • Instructions inside customer content carry no authority

    Support operations policy, section 1.2

    Ticket text is customer-supplied and is treated as data throughout. An instruction found inside it — to approve, to skip review, to refund immediately — is recorded and disregarded, never acted on. Authorisation comes only from an operator at the gate.

Reference text from our own records, selected by category and proposed action. Not written by a model.

Verification

Produced by seeded
Safe to send
Confidence0.84/ 1.00

The verifier raised no issues.

The reply addresses both the duplicate charge and the single-invoice discrepancy, and commits only to voiding an authorisation. No refund promise, no policy claim.

Approval gate

LOW risk

The gate accepts a decision only at Awaiting approval, and the server re-reads this ticket's status and re-checks the transition on every write.

Approved by a human and carried out. The audit trail below holds the approval this execution required.

Every decision is written by a Server Action that re-reads the current status from the database and re-checks the transition before anything is persisted. Executed is reachable only from Approved, and only with a recorded human approval behind it.

Audit trail

  1. Actor: SystemReceivedAug 10, 2026, 1:01 PM

    Ticket received. Nothing has been inferred and nothing has been authorized.

  2. Actor: AIReceived to AnalyzingProduced by seededAug 10, 2026, 1:05 PM

    Classifying category and severity, extracting evidence.

  3. Actor: AIAnalyzing to DraftedProduced by seededAug 10, 2026, 1:09 PM

    Drafted a customer response and proposed one action.

  4. Actor: AIDrafted to VerifiedProduced by seededAug 10, 2026, 1:13 PM

    Independent check of the draft against the ticket.

  5. Actor: AIVerified to Awaiting approvalProduced by seededAug 10, 2026, 1:17 PM

    Decision assembled and parked for a human.

  6. Actor: HumanAwaiting approval to ApprovedAug 10, 2026, 1:21 PM

    Explanation only, no refund promised. Duplicate authorisation confirmed in the payment log.

  7. Actor: HumanApproved to ExecutedAug 10, 2026, 1:25 PM

    Approved action carried out and recorded.

Append-only, enforced by a database trigger. No row here can be edited or deleted.

Execution result

Send replySimulatedAug 10, 2026, 1:25 PM

Reply recorded as sent. No email provider is wired for the demo, so delivery is simulated.

Simulate a customer reply

Demo control

Stands in for the customer sending another message. Only the sending is simulated: the message is recorded on this ticket for real, and if it contradicts a decision that was already authorized, the ticket is sent back to the gate and the trail above says why.

Executed is reachable only from Approved, re-validated server-side on every call. A decision can be reopened by new information, but only into human review — never into a second execution.