05 / A worksheet for the next review

Payment control coverage checklist

Map every declared way to pay one obligation. For each path, record who can act, what they can see and what can stop release. Keep confirmed scope, open checks and required evidence separate.

Download blank worksheet PDF · 1 page · fillable Download completed example PDF · 1 page · fictional

No signup. Complete the downloaded worksheet in a PDF reader or print it in landscape. Keep completed copies in your own approved workspace.

By Scott Lee, founder of HALTSEAL Updated October 16, 2026

THE DECISION TO MAKE

Which paths are confirmed, and which are still unknown?

Follow the evidence

Start with one obligation.

Choose a supplier, seller or contractor payment workflow. Name the review owner and date. List normal, fallback and emergency paths, including API calls, bank portals, uploaded files and scheduled jobs.

Ask both the payment owner and the people who operate the alternate paths to check the inventory. Record how it was assembled and what was not inspected. An omitted path cannot be treated as covered.

The worksheet has room for three paths. Keep entries brief and check that all text is visible before printing. Use another numbered sheet for additional paths or detail and keep the same workflow reference. Use internal references instead of account numbers, credentials or personal payment data.

SCOPE BEFORE ASSURANCE

Listing a path does not verify its control. A document review can identify questions. Confirming behavior requires matched evidence and, where appropriate, an agreed test that cannot move real funds.

Six checks for each path.

Use these prompts with the blank worksheet
Check	What to record	Evidence to seek
1. Executable path	System, route and how the instruction reaches release. Include emergency and scheduled use.	A reviewed inventory of systems, accounts, jobs and manual procedures.
2. Actor and authority	Who can prepare, approve, upload, release or override, and under what current authority.	Applicable roles, approval rules, delegations and override records.
3. Same obligation	How this path is linked to the same payable, amount and currency across different references.	A mapping from each instruction to the obligation, including partial-payment accounting if relevant.
4. State before release	What the actor can see about prior and competing attempts, when it was checked and what remains unknown.	Matched status records, source, timestamp, finality rules and any missing visibility.
5. Effective hold point	What can still prevent dispatch, who controls it and how competing releases are excluded.	A demonstrable pre-release control, including bypasses, queued work and emergency paths.
6. Evidence and follow-up	What is established, what needs checking, the missing record and the next responsible owner.	Retrievable references, a stated review method and an owner/date for every unresolved item.

A notification after dispatch is not a hold point. An API's idempotency guarantee should be recorded with its actual scope; it does not by itself establish control over a separate portal or file path. See the provider-scope guide.

A completed example, with open questions.

This invented supplier-payment workflow uses one USD 10,000 obligation, INV-0421. Its three declared paths illustrate how to record uncertainty. These are supplied fictional observations, not customer findings or a completed HALTSEAL assessment.

FICTIONAL PATH 01

A / ERP API

Actor / authority: AP service; release approval recorded in the ERP.
Same obligation: INV-0421 mapped to the ERP instruction reference.
State visible: ERP status pending. Bank outcome not yet matched.
Hold point: New ERP runs can be paused. Existing queued retries unverified.
Evidence / owner: Obtain bank outcome and retry-queue records. Owner: ERP operations.

FICTIONAL PATH 02

B / Bank portal

Actor / authority: Treasury preparer and separate release approver.
Same obligation: INV-0421 entered manually. Mapping not independently checked.
State visible: Portal shows its own entries. Original ERP outcome absent.
Hold point: Approver can withhold this instruction. Shared exclusion untested.
Evidence / owner: Verify role rights and cross-path check before release. Owner: Treasury.

FICTIONAL PATH 03

C / Uploaded file

Actor / authority: Payments operations uploads; bank sign-off required.
Same obligation: File reference differs. Mapping to INV-0421 not supplied.
State visible: Upload history available. Scheduling and replay state unknown.
Hold point: No effective stop point established for an already accepted file.
Evidence / owner: Obtain accepted-file status and schedule rules. Owner: Bank liaison.

Confirmed scope: Three paths are declared in the fictional record. A local pending status and B's two-person procedure are described; operation is not verified.
Open checks: Inventory completeness; C's obligation mapping; queued or scheduled work; coordination between B and other release paths.
Required evidence: Matched bank outcome, role records, queue/file status and an effect-suppressed test of competing release. Assign owners and review dates.

The example's useful output is a list of evidence to obtain before making a coverage claim. It does not establish that the three paths are exhaustive or that any control works in production.

Leave the meeting with three lists.

01 / CONFIRMED SCOPE

What the records support

Name the inspected path, behavior, evidence reference and review method. Limit the statement to what was actually checked.

02 / OPEN CHECKS

What still needs a check

Keep unknown paths, missing visibility, bypasses and competing releases explicit. Assign an owner and next review date.

03 / REQUIRED EVIDENCE

What would resolve it

Specify the record or effect-suppressed test needed. A blank field remains an open item, never an assumed pass.

A review may support keeping the existing controls, correcting a documented gap or collecting more evidence. A control shown on paper still needs its behavior and operating conditions established. Revisit the inventory when a bank, provider, credential, schedule or emergency procedure changes.

For a specific operational handoff, read manual bank payments while an ERP payment is pending. For a later observational evaluation, see how to evaluate Shadow decisions.

Inspect the basis

Put this question to the evidence.

R25 · Confirmed bypass
The retained events establish a failure, even when handler visibility is missing.
R35 · Evidence still missing
All four models remain INCONCLUSIVE. An unknown is not an assumed pass.

Recorded synthetic examples. These findings do not establish the behavior of your workflow.

Sources and limits

HALTSEAL: Coverage is a condition. The public model's boundary for governed and excluded paths.
Assessment preparation and scope. Readiness, evidence, effect-suppressed testing and possible findings.
Current evidence and limitations. Local results and the customer work still required.

Worksheet revision 1, September 28, 2026. This is HALTSEAL's proposed review framework. It is not a safety score, audit certification, payment authorization or proof of complete coverage. Downloads contain a blank form and a fictional example; neither connects to a bank or sends worksheet entries to HALTSEAL. Native integration and production enforcement require separate qualification.