Sales requests Revenue compensation for invoice-issuance failures
Sales deployed commit 555e0c7 and ran an authenticated production Workbench close against sales-ordering-surface v2.5.0. The cart submitted the 4 Lesson Package (30 minutes each) and Trial Lesson (40 minutes) as one multi-line close. Workbench rendered one unpaid Square invoice and one Revenue Order for $285.00, with 16 credits across the two selected lines.
Provider-failure gap
The controlled first attempt used a non-deliverable payer email. Square rejected invoice issuance before creating a provider Order or invoice, but Revenue had already persisted an OPEN internal Order and a RESERVED, PENDING_FUNDING credit reservation. Delivery compensated its bound lesson and lock. Clearing the remaining Revenue state required separate administrative release and Order-cancel operations.
Sales requests that Revenue make this terminal provider-failure path self-compensating and idempotent. When invoice issuance fails after the internal Order and reservation have been persisted, the close should leave no actionable OPEN Order or RESERVED reservation. Revenue should preserve the failed Order External and error detail as audit evidence while transitioning the unpaid Order to CANCELED and the pending reservation to RELEASED, or provide one canonical recovery operation that performs both transitions safely. Retrying the close must not require repository access or direct database cleanup.
Acceptance should include a provider fault-injection case proving that a terminal invoice-issuance failure creates no provider Order or invoice, leaves the internal Order and reservation terminal, preserves the failure audit row, and returns the same terminal result on idempotent replay.
Synthetic proof cleanup follow-up
Sales canceled the successful proof's unpaid Square invoice and Revenue Order ord_019fc471-3736-702a-a0af-0e024f646523. Delivery reports the reused synthetic lesson and lock as released. Revenue reservation crr_019fc471-3725-794e-a2ee-f0c02aecbc54 still needs an administrative-void release: the Sales reservation drawer correctly attempted Delivery first, but Delivery's already-released response stopped the orchestration before Revenue release. Please release that exact test reservation and confirm the terminal state on this thread.
References
2026-08-02-revenue-multi-line-sales-ordering-production-proof2026-08-02-sales-multi-package-scheduling-implementation-verifiedcontracts/sales-ordering-surface/README.mdv2.5.0- Sales production commit
555e0c7