Invoice, Collection, and Payment Evidence

Create accurate invoices, document delivery and acceptance, follow up consistently, and preserve a lawful evidence package when payment is late or disputed.

The result you're building

An accounts-receivable workflow with verified parties, contract-linked line items, invoice and delivery evidence, status and aging, written reminders, dispute handling, access closure, and escalation to appropriate professional channels.

Use this guide when

• A client payment is due, late, partially paid, or disputed.
• Custom work, milestones, deposits, expenses, or licenses must reconcile.
• You need a repeatable process that does not rely on threats or hidden technical leverage.

Do not use it as a substitute for

• Disabling, sabotaging, accessing, or deleting a client's system as self-help.
• Adding unauthorized fees or making legal threats without checking the agreement and applicable law.

Before you change anything

• Collect these items first. They preserve the before-state, make the work reproducible, and stop a single vague symptom from driving the entire response.
• Verified contracting/billing entity, address/contact, purchase order, tax details, and authority.
• Signed agreement/SOW/change orders, milestone, acceptance, delivery, and support records.
• Invoice number/date/due date/currency/line items/credits/taxes/payment instructions.
• Payment receipts, partials, balances, aging, reminders, replies, disputes, and promises.
• Access/repository audit, ownership/licensing conditions, evidence archive, and counsel/collection options.

Understand the system before fixing it

Terms must map to observable events
Scope, acceptance, payment, support, and ownership work only when each obligation has an owner, date, artifact, and pass/fail condition.

Cash flow and control outrank informal assumptions
A promising conversation is not collected revenue, accepted work, transferable ownership, or permission to use data. Record the actual state.

The ledger must reconcile to the agreement
Invoice line items, credits, taxes, deposits, and payment triggers should map to controlled contract and acceptance records.

Firm process beats emotional pressure
Send factual dated notices, provide a dispute path, and escalate through lawful channels. Do not improvise threats in chat.

Evidence-to-decision map

Step-by-step procedure

Work in order and retain the output from each step. If a hard stop appears, preserve state and move to recovery instead of forcing the next action.

Step 01 — Verify parties and payment basis

Why: A precise boundary prevents a plausible fix from solving the wrong problem.

Do: Confirm contracting entity, billing address/contact, authority, PO/vendor requirements, currency, tax/fee handling, and exact agreement/change version.

Read the result: Invoice is directed to the party and process obligated to pay.

Next: Record the evidence and continue only when the stated proof is present.

Step 02 — Reconcile deliverable and acceptance

Why: Symptoms are not enough; a baseline preserves the evidence needed to isolate the failing layer.

Do: Link milestone to submission date, artifact/release hash, test results, client response, defects/cure, review window, and acceptance status. Separate disputed from undisputed work.

Read the result: Payment trigger is supported by dated evidence.

Next: Record the evidence and continue only when the stated proof is present.

Step 03 — Build an accurate invoice

Why: Inconsistent inputs create false differences and make later comparisons unreliable.

Do: Use unique number, issue/due dates, parties, line items, quantities, deposit/credits, tax as applicable, total/balance, lawful late terms from agreement, and verified payment instructions.

Read the result: Arithmetic and contract mapping independently reconcile.

Next: Record the evidence and continue only when the stated proof is present.

Step 04 — Deliver and prove receipt

Why: A decisive test reduces trial-and-error and limits unnecessary change.

Do: Send through the agreed channel, preserve sent record, portal status or acknowledgment, attachment hash, and any delivery failure. Avoid exposing sensitive banking data unnecessarily.

Read the result: Accounts payable can identify, approve, and pay the exact invoice.

Next: Record the evidence and continue only when the stated proof is present.

Step 05 — Follow a consistent reminder ladder

Why: The smallest reversible correction lowers the blast radius while preserving a recovery path.

Do: Before due date, due date, late notice, dispute request, formal demand, and professional escalation should stay factual, dated, proportionate, and consistent with contract/law.

Read the result: Each communication states amount, basis, deadline, response path, and prior history.

Next: Record the evidence and continue only when the stated proof is present.

Step 06 — Resolve disputes and partials

Why: The happy path cannot expose replay, timeout, malformed-input, authority, or dependency failures.

Do: Record the client's specific basis, evidence, proposed cure/credit/payment plan, authority, dates, and written outcome. Keep undisputed balance visible.

Read the result: Ledger and acceptance record reflect the agreed resolution, not an informal promise.

Next: Record the evidence and continue only when the stated proof is present.

Step 07 — Close or escalate lawfully

Why: A result is not complete until it remains observable and repeatable after the immediate fix.

Do: After payment, issue receipt and complete authorized handoff/access closure. If unresolved, preserve the evidence package and consult appropriate counsel, court, mediator, or licensed collection channel.

Read the result: No unauthorized system access remains and the matter has a documented lawful next step.

Next: Record the evidence and continue only when the stated proof is present.

Operational worksheet

Evidence record

• Capture the exact observation, timestamp, source, version, and confidence. Sanitize credentials and personal data before sharing the record.
• Verified contracting/billing entity, address/contact, purchase order, tax details, and authority.
• Signed agreement/SOW/change orders, milestone, acceptance, delivery, and support records.
• Invoice number/date/due date/currency/line items/credits/taxes/payment instructions.
• Payment receipts, partials, balances, aging, reminders, replies, disputes, and promises.
• Access/repository audit, ownership/licensing conditions, evidence archive, and counsel/collection options.

Acceptance scoreboard

• Contracting and billing identities, authority, process, currency, and tax/fee basis are verified.
• Each line item and credit maps to agreement, change, delivery, and acceptance evidence.
• Invoice arithmetic, balance, due date, and payment instructions are independently checked.
• Delivery/receipt, reminders, replies, promises, disputes, partials, and aging are preserved.
• Technical access and ownership are handled only under agreement and law.
• Payment receipt or professional escalation closes with a complete evidence archive.

Minimum handoff record

• Versioned invoice, collection, and payment evidence scope, owner, exclusions, and success criteria.
• Sanitized evidence snapshot with source, time, version, and confidence.
• Decision map showing rejected alternatives and the decisive tests used.
• Ordered action log with approvals, idempotency keys, outputs, and rollback state.
• Acceptance results, remaining risks, review date, and escalation owner.

Worked example

Evidence collected

• Agreement and chat show $1,800 total.
• $180 receipt is documented.
• Repo invitation/access events and release hash can be preserved.
• Client legal identity and acceptance evidence are incomplete.

Decision: Create a factual ledger and evidence file, request verified billing identity and specific acceptance dispute, issue a dated invoice/demand consistent with the agreement, and seek legal advice if needed. Do not sabotage or access the client's systems.

Actions taken

• Calculated and documented the $1,620 balance.
• Archived agreement, messages, payment, release, and repo events.
• Sent a bounded acceptance checklist and payment deadline.
• Reserved professional legal/collection escalation based on jurisdiction and identity evidence.

Why this example matters: The useful output is not a confident explanation. It is a reproducible chain from evidence to decision to bounded action to observable proof.

Verify, recover, and hand off

Completion tests

• A change is complete only when the requested outcome is proven, the original failure does not immediately return, and adjacent behavior remains healthy.
• Contracting and billing identities, authority, process, currency, and tax/fee basis are verified.
• Each line item and credit maps to agreement, change, delivery, and acceptance evidence.
• Invoice arithmetic, balance, due date, and payment instructions are independently checked.
• Delivery/receipt, reminders, replies, promises, disputes, partials, and aging are preserved.
• Technical access and ownership are handled only under agreement and law.
• Payment receipt or professional escalation closes with a complete evidence archive.

Rollback or safe recovery

• Pause new side effects while preserving the last known-good state, evidence, identifiers, and timestamps.
• Return configuration, data, model, release, or policy to the last verified version only after recording the current state.
• Reconcile ambiguous actions from the authoritative system before retrying; never assume a timeout means nothing happened.
• Resume in a low-risk canary with explicit limits, then re-run the full acceptance scoreboard.

If the expected result does not appear

Reusable handoff record

• Versioned invoice, collection, and payment evidence scope, owner, exclusions, and success criteria.
• Sanitized evidence snapshot with source, time, version, and confidence.
• Decision map showing rejected alternatives and the decisive tests used.
• Ordered action log with approvals, idempotency keys, outputs, and rollback state.
• Acceptance results, remaining risks, review date, and escalation owner.

Agent delivery contract

Required inputs

Agent refusal and escalation rules

• Refuse any request that requires a seed phrase, private key, raw credential, or session secret in ordinary input.
• Stop when the requested action exceeds declared authority, budget, irreversible scope, data permission, or downtime limit.
• Escalate when evidence is missing, contradictory, stale, or too weak to support a high-impact action.
• Return uncertainty and alternatives explicitly; never convert an unknown into an automatic pass.

Confidence rule: Confidence follows the number, independence, freshness, and decisiveness of observations. Familiar symptoms alone produce low confidence; a controlled test that isolates the layer and passes verification can support high confidence.

Official reference starting points

• https://www.sba.gov/business-guide/manage-your-business/manage-your-finances
• https://consumer.ftc.gov/articles/debt-collection-faqs
• https://www.irs.gov/businesses/small-businesses-self-employed/recordkeeping