Check a new customer's reliability before credit

When to use

A customer new to the company is about to buy on payment terms (invoice after delivery). Not for lead qualification before an offer — use sales.qualify-lead. Not for an existing customer already overdue — use money.chase-overdue-invoice; if the debt is dead, money.write-off-bad-debt.

Before you start

• The customer's legal name and registration number are known — a brand name or a website is not enough;
• The owner has said (or this playbook sets) what the default terms are for a first order.
• For customers registered outside Latvia: run the same steps against that country's company register and

What a run requires1

The trail8 steps

1. S1

   Fix the identityagent

   Record the exact legal name, registration number, registered address and signatory from the contract draft or the customer's own documents.

   Done when the identity block in the memo is filled and matches the paperwork — not a trade name.

2. S2

   Check the registeragent

   Pull the customer's record from the Company Register (ur.gov.lv) via company-intel: legal status, board, share capital, founders, date of registration. Save the extract or a screenshot with the date.

   Done when the memo shows status "registered" (or the actual status) as of a dated extract.

   ⛔ A status of "dissolving", "reorganisation" or "liquidation" stops the run — surface it to the owner in S7, do not pass it silently.

3. S3

   Check public debt listsagent

   Search the VID public tax debtor list for the registration number.

   Done when the memo records the result and the date checked, including "not on the list on <date>".

   ⛔ "Not on the list" means nothing without the date — the list changes weekly. ⚠ verify current publication schedule of the VID debtor list at vid.gov.lv.

4. S4

   Check enforcement and filingsagent

   Check whether enforcement proceedings against the customer are publicly visible, and whether the last annual report was filed on time.

   Done when both results are in the memo with dates. ⚠ verify where enforcement proceedings are published in LV (sworn bailiff database) and the annual-report filing deadline in the Commercial Law — read it on likumi.lv, do not rely on memory.

5. S5

   Read the financialsagent

   From the last filed annual report: turnover, equity, result. Compare equity against the requested credit amount.

   Done when the three figures and the report year are in the memo, and a one-line judgement ("equity covers 4× the requested limit") is written.

6. S6

   Check payment behaviouragent

   If the customer bought before (even small), read our own invoice history. Otherwise ask for one trade reference and note the answer, or accept "no history" as a finding.

   Done when the memo has a payment-behaviour line: own history, reference, or "none available".

7. S7

   Decide the credit termsownerneeds approval · owner

   Approval · S7 · owner — the run stops until a named person records the decision

   Present the memo with a recommendation: limit, payment days, prepayment or delivery-against-payment.

   Done when the owner's decision is recorded in the memo: who decided, when, and the terms.

   ⛔ No memo, no credit. An oral "they seem fine" is not a decision this playbook produces.

8. S8

   Record and set the watchagent

   Attach the decision to the customer record; set the terms in the offer/contract draft; create a re-check task (re-run S2–S5 in 12 months, or at the next large order).

   Done when the re-check task exists with a due date and the customer record links to the memo.

Checks — how we know it worked

• The entity checked is the entity on the contract — registration numbers match character for character.
• Every check in the memo carries a date; none older than the current run.
• The decision names a person and a date, and states terms in numbers (days, amount), not adjectives.
• The re-check task exists and is linked to the customer.

If it goes wrong

What each step leaves behind

1. S1the identity block in the memo is filled and matches the paperwork — not a trade name.
2. S2the memo shows status "registered" (or the actual status) as of a dated extract.
3. S3the memo records the result and the date checked, including "not on the list on <date>".
4. S4both results are in the memo with dates. ⚠ verify where enforcement proceedings are published in LV (sworn bailiff database) and the annual-report filing deadline in the Commercial Law — read it on likumi.lv, do not rely on memory.
5. S5the three figures and the report year are in the memo, and a one-line judgement ("equity covers 4× the requested limit") is written.
6. S6the memo has a payment-behaviour line: own history, reference, or "none available".
7. S7the owner's decision is recorded in the memo: who decided, when, and the terms.
8. S8the re-check task exists with a due date and the customer record links to the memo.

Evidence to keep

The memo itself · dated register extract or screenshot · debtor-list result with date · annual-report figures with year · trade reference answer · the S7 decision (who, when, terms) · the re-check task id.

How this playbook improves

After every 10 runs ask: of the customers who passed, how many went overdue anyway, and what did the memo miss? How long from ask to decision, and which step waited longest (usually S6 references)? Were any re-check tasks never run? A new version changes the step that caused the misses, and says so in its change note.