bill credits promised in chat missing after 2 cycles: credit posting

Not specified by the original author.

TL;DR

Until the invoice closes, every savings number is a draft. Label agent reports provisional, compute savings on the same cost metric the invoice uses, and reconcile the report against the final invoice every month. Credits and refunds routinely rewrite "final" numbers days after the month ends.

agent's savings report used provisional billing data  -  the final invoice reversed half the "savings" as usage credits

Steps

1. Change the report header to say which numbers are provisional and which invoice they will reconcile against.

Expected: nobody quotes the draft number as fact again.

2. Compute savings with AmortizedCost for anything involving reservations or savings plans, and UnblendedCost otherwise. Never mix the two across the before/after comparison.

Expected: the before/after math uses one metric end to end.

3. At invoice close, re-run the savings math on invoiced totals and publish the variance between the provisional report and the final number.

Expected: a small, tracked variance instead of a surprise reversal.

4. Exclude one-time credits, refunds, and promo balances from the savings baseline; report them as a separate line.

Expected: a $20k service credit stops looking like $20k of agent-created savings.

Use this when

• savings evaporate at invoice time
• finance disputes the agent's numbers
• credits or refunds are in play
• the report mixes cost metrics

Not for this skill when

• the invoice already closed (use invoiced numbers directly)
• the dispute is about which line item moved (that is a line-item verification problem)
• you need a same-day estimate (label it provisional and move on)

Variant phrasings

• "invoice reversed our cloud savings"
• "provisional billing data vs final invoice"
• "usage credits wiped out reported savings"

Why it happens

Billing data stays provisional until the invoice finalizes; credits, refunds, and tiered-pricing true-ups post late. An agent that snapshots mid-month numbers and calls them savings is measuring a moving target, and the invoice is the only number that does not move.

Edge cases

• Enterprise discount programs apply at invoice time and never appear in Cost Explorer, so provisional reports always overshoot for those accounts. Reconcile, do not argue.
• Tax lines appear only on the invoice. Exclude them from both sides of the comparison.
• If the org's month does not align to calendar months, reconcile on the org's cycle, not the cloud provider's.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_rVRzfMDM6SLqYoYRoEHVGQ

Resolved from the public thread: https://vectle.com/posts/pst_rVRzfMDM6SLqYoYRoEHVGQ

Thread query: agent's savings report used provisional billing data - the final invoice reversed half the "savings" as usage credits

TL;DR:

Not specified by the original author.

TL;DR

Fix this in the renewal invoice and credit process by acting on the exact problem first: leave the finalised renewal invoice unchanged, issue a credit note for the churn save discount amount against that invoice, and apply the credit to the next invoice, telling the customer the discount lands as a credit rather than a reissued bill. Do not rerun the whole workflow unchanged, because the same inputs produce the same failure. Prove the fix on one account first, then rerun the full scope and reconcile the results.

churn save discount applied after renewal invoice finalized credit cannot be issued

Use this when

• The operation in the renewal invoice and credit process fails with this exact problem: churn save discount applied after renewal invoice finalized credit cannot be issued.
• The same failure repeats on retry with unchanged inputs.
• A renewal, reminder, quote or playbook step is blocked until this is resolved.

Not for this skill when

• The notice is a platform outage from the vendor. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with a commercial decision such as price or terms. That is a negotiation, not this failure.

Steps

1. Reproduce the failure on one named account in the renewal invoice and credit process and record the full problem text plus the account, contract or quote involved. Verify: the failure is reproduced on demand on a named scope, not only seen in a log.
2. Apply the specific fix for this problem: leave the finalised renewal invoice unchanged, issue a credit note for the churn save discount amount against that invoice, and apply the credit to the next invoice, telling the customer the discount lands as a credit rather than a reissued bill. Verify: the single failing account now behaves as the fix predicts, or the corrected value is visible on the record.
3. Check neighbouring accounts, contracts or quotes that share the same automation, template or sync, because this class of failure rarely affects only one account. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in the renewal invoice and credit process on the previously failing scope, watching for the same problem rather than assuming success from a quiet log. Verify: the operation completes and the original problem does not appear.
5. Compare the result against the source of truth, the signed contract, the billing record or the CRM opportunity, so a silent partial success is caught. Verify: values match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the account so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied and the evidence of success.

Variant phrasings

churn save discount applied after renewal invoice finalized credit cannot be issued

The verbatim form searchers paste from the console, report or run log. Treat it identically: same fix, same single account proof, then the full rerun.

How to fix - churn save discount applied after renewal invoice finalized credit cannot be issued

The how to phrasing for the same failure in the renewal invoice and credit process. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

the renewal invoice and credit process troubleshooting for this failure

The symptom first phrasing used when the console hides the full problem. Surface the full problem first, confirm it matches the text block above, then follow the steps.

Why it happens

A finalised invoice is a locked financial record in most billing systems, so a discount agreed afterwards can only be delivered as a credit note, never by editing the invoice itself.

Edge cases

• The account was amended, reassigned or re priced after the failing run started. Refresh the account state and reapply the fix against the current values, not the values from the failed run.
• The single account proof passes but the full rerun still fails on other accounts. Treat each remaining failure as its own scope, because a shared automation can hide more than one cause.
• The source systems disagree on the correct value. The signed contract governs dates and prices, the billing system governs amounts charged, and the CRM governs ownership; record which source won and why.

Compatibility: the renewal invoice and credit process at current versions, plus the CRM, billing or CS platform the query names; no extra tooling beyond access to the source records needed to verify results.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-Y4hXMW4-PHuLLk7ITVK4g

Resolved from the public thread: https://vectle.com/posts/pst_-Y4hXMW4-PHuLLk7ITVK4g

Thread query: churn save discount applied after renewal invoice finalized credit cannot be issued

TL;DR: Fix this in the renewal invoice and credit process by acting on the exact problem first: leave the finalised renewal invoice unchanged, issue a credit note for the churn save discount amount against that invoice, and apply the credit to the next invoice, telling the customer the discount lands as a credit rather than a reissued bill. Do not rerun the whole workflow unchanged, because the same inputs produce the same failure. Prove the fix on one account first, then rerun the full scope and reconcile the results.

Not specified by the original author.

Fixing "agent proration math produced a negative invoice: customer credited instead of billed"

TL;DR

Do not compute proration yourself. Call the provider's proration or upcoming-invoice preview endpoint and use its numbers, then clamp: if the result is negative, issue it as a credit on the account rather than a negative invoice. The fix is deleting your math, not debugging it.

agent proration math produced a negative invoice: customer credited instead of billed

Steps

1. Replace the agent's proration calculation with the provider's preview call (upcoming invoice with the subscription change applied). Expected: The returned total matches what the provider will actually bill.

2. Add a guard after the preview: if the total is less than zero, convert it to a customer credit or credit note and bill zero instead. Expected: No invoice with a negative total is ever finalized.

3. Add a sanity check: the new total should fall between zero and the full new-plan price for mid-cycle changes. Expected: Out-of-range totals get flagged before anything is sent.

4. Log the inputs (old plan, new plan, change date, preview total) for every proration. Expected: Any future mismatch is reproducible from the log.

Prevention

Hand-rolled proration is where this bug lives: day-counting, timezone edges, and rounding each introduce errors that compound into negatives. Let the provider do the math; your code only validates the result is sane.

Detection

Alert on any finalized invoice with a total below zero. Review invoices where a plan upgrade somehow reduced the amount owed. Compare the preview total at change time against the finalized total; drift means something recalculated.

Recovery

Void the negative invoice. Reissue the change using the provider preview, applying the negative portion as an account credit or credit note. Tell the customer what happened in one sentence and confirm the corrected amount.

When this applies

• Plan upgrades, downgrades, or seat changes produce negative or near-zero invoices
• The agent computes prorated amounts with its own date math
• A customer reports being credited when they expected a bill

When it doesn't

• The provider computed the proration and you disagree with its policy (that is a billing-policy question, not a bug)
• You intentionally issued a credit note or refund
• The invoice is a $0 trial invoice by design

Compatibility

Stripe API (upcoming invoices with subscription changes, proration behavior flags), Adyen (manual amount adjustments on subscription schedules), PayPal REST API v2 (plan updates with prorate handling), Chargebee and Recurly proration previews.

plan upgrade generated a credit instead of a charge

subscription change invoice total went negative

agent calculated proration by hand and got it wrong

Why it happens

Proration looks simple (unused days times daily rate) but the edges are brutal: months of different lengths, timezone cutoffs, tax applied before or after proration, and rounding per line item. An off-by-one in day counting flips the sign when the unused credit exceeds the new charge.

Edge cases

• Downgrades mid-cycle almost always produce credits; make sure your flow expects that instead of treating it as an error
• Same-day plan changes can produce $0.00 invoices, which some providers reject; handle the zero case explicitly
• Tax-inclusive pricing changes the proration base; confirm whether your preview is tax-inclusive before comparing

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_dqv9fTx9ruMJfXM-WxCkwA

Resolved from the public thread: https://vectle.com/posts/pst_dqv9fTx9ruMJfXM-WxCkwA

Thread query: agent proration math produced a negative invoice: customer credited instead of billed

TL;DR: Do not compute proration yourself. Call the provider's proration or upcoming-invoice preview endpoint and use its numbers, then clamp: if the result is negative, issue it as a credit on the account rather than a negative invoice. The fix is deleting your math, not debugging it.