What a Read-Only Revenue Leak Scan Actually Looks For

A read-only Revenue Leak Scan answers one narrow question: which authorized business records appear to have stalled before reaching a clear outcome?

It is not a collection campaign, a database cleanup, or a forecast. It does not contact a customer, change a status, create a job, or write back to the connected source. The output is a reviewable set of candidate opportunities with the evidence used to identify them.

What the scan reads

The available categories depend on the records and permissions exposed by the connected source. A useful scan may inspect fields such as:

• record type and source identifier;
• current status;
• issue, sent, transition, due, and update dates;
• estimate total or current invoice balance;
• related job or customer identifiers needed to correlate the record; and
• source events that show approval, payment, or another resolution.

It should request only the scopes needed for those queries. A read-only financial scan does not need permission to edit customers, send messages, or create source-system records.

The candidate categories

Unresolved estimates

The scan looks for estimates that were presented but have not reached approval, decline, conversion, archive, or another clear outcome after the applicable review window. It should exclude recent quotes and records already linked to a resolved path.

Approved work without a clear next step

Where source relationships support it, an approved estimate with no scheduled or converted work may deserve review. Parts, permits, customer timing, or off-system scheduling can make this a false positive, so the source evidence matters.

Completed work that may not be billed

Some systems expose enough job and invoice state to identify work that appears complete without a collectible invoice. This category needs careful exclusion rules for warranty work, internal jobs, deposits, and normal office review.

Overdue invoices

The scan can identify invoices with a positive current balance after the recorded due date. It should account for void, paid, draft, bad-debt, and other non-actionable statuses exposed by the source.

The broader revenue leak guide explains what each category means operationally.

How the scan decides a record deserves review

A production-shaped rule has four parts:

1. Eligibility: The source type and status are in a category the scan supports.
2. Timing: The record is past the business-defined point when a next step should exist.
3. Value: The source shows a positive amount relevant to the category.
4. Exclusions: A resolved status, duplicate, payment, opt-out, dispute, or missing evidence removes or diverts the candidate.

The rule should preserve its inputs. If an owner asks why a record appeared, the system should show the status, dates, amount, related record, and rule version rather than a mysterious score.

What happens to contact information

A scan may need limited customer identifiers to correlate records or show whether a future action could be possible. That does not make outreach permissible. Channel consent, opt-outs, contact validity, and use-case rules belong to a separate action decision.

Public acquisition analytics should not receive customer names, phone numbers, email addresses, invoice identifiers, or raw source payloads. Funnel tracking can use coarse categories, event names, and revenue bands instead.

What the scan does not prove

A candidate is not proof that:

• the customer still wants the work;
• the estimate remains valid;
• the invoice is undisputed;
• the balance is collectible;
• the record has no off-system resolution; or
• a later payment should be attributed to RelayHitch.

Those are owner-validation and outcome questions. The scan makes the uncertainty visible; it does not erase it.

A sample result, without inflated claims

Suppose a source has 200 estimates and invoices in the review window. The scan flags 14 records with a combined source value of $18,000. After review, the owner marks six as valid opportunities, three as already resolved, two as duplicates, and three as needing investigation.

The correct report says the scan identified 14 candidates representing $18,000 in source value and the owner validated six. It does not say RelayHitch recovered $18,000. If later evidence shows a validated invoice was paid or an estimate converted, that outcome enters a separate value ledger.

Why read-only comes first

The first run tests data quality and rule quality. If the source is stale or the exclusions are weak, the owner should learn that before a customer receives anything. Read-only review also creates the baseline needed to measure false positives and tune categories.

Paid Recovery is a separate product decision. Checkout alone should not activate customer outreach. The business still needs to choose categories, channels, sending identities, limits, consent rules, suppressions, and escalation paths, and the delivery system must be explicitly enabled.

Run a free Revenue Leak Scan to inspect the available categories and evidence in your authorized records.