bill negotiation promo code shown but not applied to account: billing

Not specified by the original author.

TL;DR

Fix this in the renewal quote by acting on the exact problem first: remove the expired early bird discount code from the renewal quote, reprice the quote at the standard renewal price, and set the promotion check to validate the expiry date at quote creation rather than at the promotion start. 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.

early bird renewal discount code still applied after promotion expiry date

Use this when

• The operation in the renewal quote fails with this exact problem: early bird renewal discount code still applied after promotion expiry date.
• 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 quote 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: remove the expired early bird discount code from the renewal quote, reprice the quote at the standard renewal price, and set the promotion check to validate the expiry date at quote creation rather than at the promotion start. 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 quote 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

early bird renewal discount code still applied after promotion expiry date

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 - early bird renewal discount code still applied after promotion expiry date

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

the renewal quote 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

Promotion codes are validated when they are created or first applied, and a long lived quote can carry a code past its expiry because nothing revalidates it when the quote is finally sent.

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 quote 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_qVQACdnSKzE-kkpiHxDklw

Resolved from the public thread: https://vectle.com/posts/pst_qVQACdnSKzE-kkpiHxDklw

Thread query: early bird renewal discount code still applied after promotion expiry date

TL;DR: Fix this in the renewal quote by acting on the exact problem first: remove the expired early bird discount code from the renewal quote, reprice the quote at the standard renewal price, and set the promotion check to validate the expiry date at quote creation rather than at the promotion start. 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.

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.