SAYLOR The result you are building
Finished Result:
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.
Stop Before Proceeding:
Preserve evidence and stop retaliatory technical action. If identity, contract, ownership, jurisdiction, or collection rights are unclear, use qualified legal advice before escalating.
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
Start with the row that most closely matches the evidence. The first test isolates a layer; it is not permission to
make every available change.
Evidence Likely layer First decisive check What the result means
Client says amount is Contract/ledge Map each line/credit to Scope, deposit, tax, or arithmetic may not reconcile.
wrong r agreement and change record
Client says work not Acceptance Review submission, tests, Acceptance evidence or contract mechanism is incomplete.
accepted rejection, cure, and review
window
Invoice went to Billing identity Verify entity, address, PO, and Delivery did not reach the authorized payment path.
wrong contact accounts-payable process
Partial payment Allocation Trace receipt, currency, fees, Ledger misapplies deposit or processing/FX amount.
unclear date, and invoice allocation
Client disappeared Commercial Preserve agreement/payment/ Identity and staged handoff controls were insufficient; legal
after repo access risk access/release evidence recovery is fact-specific.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.
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.
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.
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.
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.
Procedure continued 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.
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.
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.
Decision rule SHIP / AUTOMATE GATE Proceed only when every required acceptance check is supported by direct evidence, rollback is available, and the remaining risk is explicitly owned. Unknown is not a pass.
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
Starting Problem:
A client owes $1,620 after paying $180 on an $1,800 software agreement and may have downloaded the private repository.
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.
Proof Of Completion:
The balance, basis, delivery, access, acceptance status, communications, and next lawful action are preserved in one auditable record.
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 What happened What it usually means Next safe move
Client says amount is wrong Scope, deposit, tax, or arithmetic may Map each line/credit to agreement and change record not reconcile.
Client says work not accepted Acceptance evidence or contract Review submission, tests, rejection, cure, and review window mechanism is incomplete.
Invoice went to wrong contact Delivery did not reach the authorized Verify entity, address, PO, and accounts-payable process payment path.
Partial payment unclear Ledger misapplies deposit or Trace receipt, currency, fees, date, and invoice allocation processing/FX amount.
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
Field Type Requirement
target object Versioned environment, resource, identity, or workflow being evaluated.
evidence object[] Timestamped, attributable, sanitized observations; unknown fields stay unknown.
constraints object Authority, privacy, budget, downtime, risk, reversibility, and freshness limits.
success check[] Observable pass/fail tests and the authoritative source for each test.
Returned output
Field Type Requirement
diagnosis object Likely layer, supporting and conflicting evidence, alternatives, and confidence.
plan step[] Ordered bounded actions with owner, risk, expected proof, and stop condition.
verification check[] Observed pass/fail/unknown results, not inferred success from command exit alone.
handoff object Sanitized evidence record, recovery state, remaining risk, and next review trigger.
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