A Tax Refactor That Could Cause Billing and Invoice Drift

Factor Review — What could break?

Verdict: REVIEW_REQUIRED

Merge blocker

Can we add an end-to-end test that validates tax amounts on the final invoice after a retry of the checkout flow?

---

Potential failure scenarios

1. Tax billing mismatch causing incorrect tax on invoices/orders

When this happens

Checkout flow invokes updated tax calculation functions (e.g. _update_checkout_tax) leading to downstream invoice generation.

How it unfolds

checkout.service._update_checkout_tax → tax.calculation.stripe.calculate → invoice.generator._tax_item_label → invoice.service.create_payout_invoice → invoice rendered to user

Evidence

• Type: inferred
• First observable signal: Finance monitoring dashboards flag invoice total vs. charged amount discrepancy; audit logs show tax variance
• Silent failure: yes
• CI would catch: no
• Merge risk: HIGH

Confidence trap

• False confidence reason: Unit tests mock tax rates and do not exercise real breakdown logic, giving a false sense of correctness.
• Why it slips through: CI lacks integration tests that run the full checkout-to-invoice pipeline with real tax breakdown data.
• Merge confidence trap: Assuming tax logic is a pure function already covered by existing unit tests.

Confidence

0.78

What breaks

Customers are billed incorrect tax amounts, triggering compliance violations, refunds, and loss of trust.

---

2. Idempotency break leading to duplicate order processing on retry

When this happens

Transient failure during order.handle_payment triggers a retry of the same order creation path.

How it unfolds

order.service.handle_payment → order.service._create_order_from_checkout → payment gateway call → database write of order record

Evidence

• Type: inferred
• First observable signal: Duplicate order IDs appear in order logs; inventory counts go negative; alerts from duplicate-payment monitoring
• Silent failure: yes
• CI would catch: no
• Merge risk: HIGH

Confidence trap

• False confidence reason: Existing tests assume a single successful execution path and never simulate retries or network glitches.
• Why it slips through: Retry logic is exercised only in production; CI does not mock failure-and-retry scenarios.
• Merge confidence trap: Belief that database unique constraints or existing business logic automatically guarantee idempotency.

Confidence

0.72

What breaks

Duplicate orders, double inventory deduction, possible double charge to customers, leading to revenue leakage and support overhead.

---

3. Partial update drift between checkout tax data and invoice rendering

When this happens

Checkout updates tax breakdown fields but invoice.generator does not consume the new fields when building the invoice.

How it unfolds

checkout.service._update_checkout_tax → order.service._create_order_from_checkout → invoice.generator.from_order → invoice.generator.displayed_tax_items → invoice PDF generation

Evidence

• Type: inferred
• First observable signal: Customer complaints about mismatched tax on receipt vs. invoice; discrepancy alerts in reconciliation jobs
• Silent failure: no
• CI would catch: no
• Merge risk: MEDIUM

Confidence trap

• False confidence reason: Tests use static fixture data that already matches the new fields, so they never detect the drift.
• Why it slips through: No end-to-end test validates that the invoice generator reflects the latest checkout tax fields.
• Merge confidence trap: Assuming the invoice generator automatically stays in sync with checkout data without explicit mapping updates.

Confidence

0.68

What breaks

Invoices show tax totals that differ from what was actually charged, causing customer confusion, support tickets, and potential legal exposure.

---

Hidden impact

• checkout tax calculation
• invoice generation
• billing reconciliation

---

Checked risk areas

• checkout
• order
• invoice
• tax
• payment

---

Missing tests

• End-to-end integration test that runs a full checkout flow, triggers tax calculation, forces a retry of order.handle_payment, and validates that the final invoice tax amount matches the charged amount.

---

Risky assumptions

• Tax calculation functions are pure and idempotent.
• Invoice generator automatically stays in sync with checkout tax fields.
• Order creation is inherently idempotent without explicit guards.

---

Silent failure summary

Changes to tax calculation and checkout flow can silently produce incorrect tax amounts or duplicate processing. Existing unit tests miss these scenarios because they mock external services and do not exercise retry paths.

Merge risk statement

The PR introduces high-severity financial risks that are not covered by existing tests. Merging could cause tax misbilling, duplicate orders, and compliance issues.

Verdict rationale

REVIEW_REQUIRED because three high-severity failure scenarios (tax_billing_mismatch, idempotency_break, and partial_update_drift) have confidence ≥ 0.6 and affect core financial pathways. The impact is significant and not caught by current CI.

---

_{Generated by Factor — validate before merging.}