# Why use Countersign?

A payment can have a valid wallet address, a correct signature and a successful transaction while still being the wrong business payment. The invoice may repeat a paid period, use superseded terms, lack required acceptance or compete with cash already committed elsewhere. Countersign is designed to bring those questions into the review before execution.

## The missing connection is the obligation

An invoice is a request. An agreement defines the obligation. Acceptance establishes the customer's required approval. Payment history shows what is already committed or delivered. A cash plan determines what can be funded now.

Those records often live in different places. Countersign connects them into a versioned decision: which checks passed, which evidence is missing, who needs to act and whether the result can be executed under the current mode. Its value proposition is a clearer operational decision with an inspectable basis. Actual time savings and error reduction must be measured in a real workflow; they are not established by the demo.

## When it is a useful fit

Countersign is designed for teams paying external vendors under recurring retainers or clearly specified delivery terms, especially where a Safe and USDC settlement are part of the workflow. It is useful to investigate when repeated questions include “Did we approve this period?”, “Was this already paid?”, “Who accepted the delivery?” and “Can we fund this without using reserved cash?”

For example, a small business working with a recurring development vendor may collect an invoice, approved scope, pull-request evidence and customer acceptance. The same review should also check a manual payment made outside the application. Countersign keeps those facts separate and compares them before recommending payment.

## Start with better review

The product does not require a leap from a spreadsheet to unrestricted automation. Observe mode is intended for read-only review. Prepare produces an explained proposal while retaining human signing. Delegate is a separately installed, limited authority for an engagement after deployment and recovery gates are met.

This progression lets a team discover weak evidence, unclear acceptance and incomplete history before granting spend rights. See [start read-only](/docs/start-read-only).

## What it is not trying to decide

A verifier cannot prove that creative work is good, that a customer is satisfied, or that an agreement has no legal ambiguity. The business defines the terms and allowed acceptors. A model may help read or explain evidence; it cannot certify its own work or override the rules.

Countersign is also not a general-purpose treasury optimizer, a bank account, an unrestricted agent wallet or a replacement for a bookkeeper's close process. Current currency and route support is constrained. If the workflow requires automatic FX, arbitrary contract execution or a fully operating hosted payment service today, read the [release status](/docs/release-status) and supported integration boundaries first.

## Evaluate it with a concrete cycle

Pick a consented set of invoices with known terms and outcomes. Measure the existing workflow, a strong rules-only review and rules plus optional agent assistance on the same point-in-time cases. Track review time, incorrect holds, missed issues, accepted escalations and completion by due date. Keep synthetic demonstrations apart from real business results.

Success means a business can explain a payment, resolve an exception and repeat the workflow with less avoidable work while preserving its authority. A high volume of model messages or a collection of transaction hashes does not demonstrate that outcome.

Read [getting started](/docs/getting-started), [agreement-aware payments](/docs/agreement-aware-payments) and [evaluation](/docs/evaluation) for the practical next steps.