The category map separates specified examples from recorded gaps. The table lists a scenario or finding for each rule requiring proof; a listed scenario may still be proposed. Executable bindings cover their cited assertions, while the transition, permission and invariant registers identify combinations that need further proof.
Create receipt-derived credit and attempt source void, cancel an unused grant and retry an eligible void. Compare a settled card’s refused void with a refund request, then redeliver a bank-return event after recovery. In another branch, recover an uncertain credit-and-card settlement before evaluating reversal eligibility.
Credit protects its source until cancellation; a settled capture uses refund treatment; replayed return confirmation restores debt once and leaves no available receipt money. The complete chain remains proposed until one executable run proves its combined outcomes.
Coverage
Rulecovered
Transitiongap: FND-ACC-TRX-078
Validationcovered
Permissioncovered
Edgecovered
Failurecovered
Boundarygap: FND-ACC-TRX-078
Concurrencygap: FND-ACC-TRX-078
Invariantgap: FND-ACC-TRX-078
Interactioncovered
Test Scenarios
10 scenarios proving CAP-ACC-TRX-013; 8 bound to an existing test.
01Reversal needs authority and valid inputpermissionapinegativetest
[
{
"do": "Attempt reversal without authority, invalid kind or missing reason, and unauthorized void.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/e2e/payment-reversals.e2e.spec.js#it is refused the reverse route without accounting.payments.reverse and the reversals read without .read (403)"
}
]
[
{
"do": "Submit bank return for check and bounced-check reversal for card and cash.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it refuses a kind the method does not allow (reversal_kind_mismatch): an ACH return of a check, a bounced check of a card"
}
]
[
{
"do": "Record bounce, attempt another reversal and repeat the first request.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it reverses the live allocation so the line owes again, and the payment item’s facts sum to zero (FC-16)"
}
]
Expected
Returned receipt has 50.00 reversed and zero net money facts; second reversal fails and replay retains the first.
[
{
"do": "Void the payment, void its credit, then retry payment void.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it refuses a payment with a credit made from it that is not void (payment_has_credit)"
}
]
Expected
Initial reversal fails and clearing the credit permits restoration of all applied debt.
[
{
"do": "Void that receipt.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/integration/services/settlements/card-fees.integration.spec.js#it credits the fee invoice whole once the void reopens it: no money, no fee; the invoice owes again"
}
]
Expected
The fee invoice is fully credited and billed debt reopens.
[
{
"do": "Win a card inquiry, target a check, exceed receipt value and reclose the inquiry.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it refuses closing a closed dispute (dispute_not_open), a dispute of a check (reversal_kind_mismatch) and an amount beyond the payment"
}
]
Expected
Inquiry conclusion moves no money and invalid or repeated disputes fail.
Separate card disputes represent chargeback and inquiry.
Steps
[
{
"do": "Close both as lost.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/integration/services/payments/dispute-inquiry-lost.integration.spec.js#it writes no payment reversal and leaves the payment succeeded, nothing reversed"
}
]
Expected
Chargeback reverses with reconciliation evidence; inquiry preserves the receipt.
An isolated workspace has eligible customers, products, matching accounts, an open period and two open batches. Each branch owns separate financial records.
Steps
[
{
"do": "Create receipt-derived credit and attempt source void, cancel an unused grant and retry an eligible void. Compare a settled card’s refused void with a refund request, then redeliver a bank-return event after recovery. In another branch, recover an uncertain credit-and-card settlement before evaluating reversal eligibility.",
"provenance": "proposed",
"source": "services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it reverses the live allocation so the line owes again, and the payment item’s facts sum to zero (FC-16); services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it refuses reversing it again (payment_not_live) and replays the same key as the same reversal; services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it refuses a payment with a credit made from it that is not void (payment_has_credit); services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it fails a void the processor says is already settled (payment_settled): the reversal failed, the payment untouched; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-007-resolve-lost-processor-answers-and-clear-bank-debits.md#WF-ACC-TRX-007; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-011-void-or-reverse-a-payment-and-follow-its-disputes.md#WF-ACC-TRX-011; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-013-apply-payment-events-from-the-integration-platform.md#WF-ACC-TRX-013; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-013-undo-a-payment-whose-money-did-not-stay.md#BR-CAP-ACC-TRX-013-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-013-undo-a-payment-whose-money-did-not-stay.md#BR-CAP-ACC-TRX-013-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-013-undo-a-payment-whose-money-did-not-stay.md#BR-CAP-ACC-TRX-013-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-013-undo-a-payment-whose-money-did-not-stay.md#BR-CAP-ACC-TRX-013-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-10; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-09; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-09; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-10"
}
]
Expected
Credit protects its source until cancellation; a settled capture uses refund treatment; replayed return confirmation restores debt once and leaves no available receipt money.
Data
Separate command keys, two customers, invoice lines, receipts and credit; controlled processor outcomes and a fixed calendar where the branch requires them.