---
id: TST-ACC-TRX-149
title: Remittance rules suite
kind: unit
product_area: accounting
module: transactions
revision: 1
status: draft
source_sha:
  services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8
repository: services-accounting
files:
  - modules/transactions/tests/unit/rules/remittance-rules.spec.js
implements: []
implements_parts: []
environment: local
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 1
isolation: In-memory fixtures and test-controlled collaborators.
provenance: test
source: >-
  services-accounting:modules/transactions/tests/unit/rules/remittance-rules.spec.js
evidence:
  - provenance: test
    source: >-
      services-accounting:modules/transactions/tests/unit/rules/remittance-rules.spec.js
    assertion_titles:
      - a remittance’s arithmetic
      - answers the lines’ sum when the total is the lines plus the remainder
      - >-
        answers the lines’ sum with no remainder when the total is the lines
        exactly
      - >-
        refuses a total above the lines plus the remainder:
        remittance_total_mismatch, never an inferred remainder
      - >-
        refuses a total below the lines plus the remainder:
        remittance_total_mismatch
      - >-
        adds up the worked example of §7.5: 208 lines of 180.00 and 720.00 over
        them make 38,160.00
      - the payments a remittance makes
      - >-
        makes one payment per bill-to in the order each first appears, a
        bill-to’s lines together
      - >-
        puts the remainder on a payment of the remitter’s own, after the others,
        allocated to nothing
      - >-
        puts the remainder on the remitter’s payment when the remitter is a
        bill-to among the lines: one payment per party
      - makes no remitter’s payment when nothing is left over
      - tells a contact and an organization of the same id apart
      - the keys a remittance derives
      - 'records payment n under K:payment:n and voids it under V:void:n'
      - >-
        derives the same key from the same request, so a retry meets the payment
        it already recorded
      - >-
        stays inside the ledger’s bound for the longest key (200) and the last
        payment of the most lines
    imports:
      - 'const { expect } = require(''chai'');'
      - >-
        const { IDEMPOTENCY_KEY_MAX_LENGTH } =
        require('@rhythmsoftware/macroservice-idempotency/claim');
      - >-
        const { MAX_REMITTANCE_LINES } =
        require('../../../db/remittance-lines.table');
      - '} = require(''../../../services/remittances/remittance-rules'');'
    test_double_declarations: []
---

# Remittance rules suite

## Verification Boundary

The suite exercises financial calculations and input contracts in an isolated test process. Registration records the existing executable file; it does not report a run or establish product approval.

## What This Suite Proves

The executable assertions exercise this module, but no capability or feature scenario binding is established for this file. Its individual assertion titles remain in the evidence register for subsequent mapping.

## What It Does Not Prove

Pure calculations and doubled collaborators do not establish database persistence, route authorization or deployed behavior. An unbound feature chain remains proposed, and this registration carries no execution result.

## Real Dependencies and Test Doubles

The imported calculation or contract runs with the fixtures and collaborators declared by the test. The evidence register retains those declarations so the boundaries can be inspected.

## Must Not Be Doubled

The calculation or contract being asserted must remain real; replacing it with a predetermined result removes this suite’s evidence.