The customer chased for money they sent
A Texas fire protection contractor of about 280 people is hiring someone to match every customer payment to its invoices. Here is how a paid invoice ends up in collections, what went wrong for others who let software do the matching, and a build that posts only what is certain.
How to use this page
Read the story, then the map. If no one in your business holds the middle square, start there, not with the build. If someone does, read what went wrong for others, then copy the build kit into your AI agent.
In October 2026 a privately owned fire protection and life safety contractor in Stafford, Texas listed a Cash Application Specialist. The lines that carry the job: “Research payments received without sufficient remittance information or clear customer identification” and “Maintain and actively manage the unapplied cash balance, with the goal of resolving unidentified and unapplied payments as quickly as possible.” The posting names no software beyond “general accounting or ERP systems” and gives no pay.
Here is how it goes today. On a Monday at 8:10 am a property management firm pays $9,400 by bank transfer for 14 inspection invoices across six buildings. It emails the note saying which invoices, the remittance, to the salesperson, not to accounts receivable. The specialist sees a bank line with a short code, finds no customer by that name, and parks the money as unapplied cash: in the bank, on no invoice.
She has about 30 payments a day to place. The $9,400 waits. On Wednesday morning her colleague in collections works the list of overdue invoices and emails the customer: 14 invoices past due. That afternoon the customer replies that they paid on Monday. She finds the deposit and splits it across the 14 invoices by hand, in about 40 minutes.
Nobody here is careless. The money and the note that explains it travel separately, customers pay under names the books do not know, and one payment can cover a dozen invoices or fall short of one for a reason nobody wrote down. Software that matches bank lines handles the clean ones; the rest pile up as unapplied cash, and every dollar there makes a paid invoice look open.
The customer, the deposit, the 14 invoices, the days and the times are an example. The 30 payments a day, the one in three that need research and the minutes are estimates from public revenue figures and surveys; the posting gives no counts.
The map: the same job as a system
The judgment it all runs on sits in the middle square, held by a person. Around it, the work in the order it moves, each square run by the machine or by a person. Along the bottom, what it runs on.
The middle is which invoice each unclear payment is for, and what a short payment means. The cash application specialist holds it, with the credit and collections manager.
The same job as a system. The middle is the judgment about which invoice an unclear payment is for and what a short payment means, held by the specialist. The deposit comes in on the left; across the top the machine finds the remittance, matches the invoices and posts what is certain; on the right the specialist settles the rest. Along the bottom is what it runs on: the triggers and the switch, the counts, and the names and rules that decide what posts on its own.
- Runs on its own
- A person does it
- The judgment it all depends on
- What it runs on
Who holds the middle square
The cash application specialist, with the credit and collections manager. Which customer and which invoices an unclear payment is for, and whether a short payment is a dispute, money held back until a job is finished, a credit or a mistake.
Before you build, these must already be true in your business:
- Every customer payment lands in a bank account the accounting system already reads.
- Customers are asked to send their remittance to one receivables inbox.
- Someone decides every short payment, write-off and credit hold, and the specialist knows who.
Still deciding whether to do this, or no one holds this judgment yet? See the verdict: what it costs today, what to hand over, the bill and the owner
What went wrong for others, and the rules it gives the build
Four things that went wrong for people who did this job, or that tripped them up, and the rule each one gives the build.
“QB allocated payments from one invoice to another, then put PIF for invoices that were not PIF.”
A small business owner on the QuickBooks community, September 2025; the fix offered was to turn off automatic credit application. Read it
The rule: Post a payment on its own only when the remittance names the invoices and the amounts agree to the cent; never apply credits automatically.
Clients “mark invoices as paid by their customer on the day they receive the promise to pay”, then “apply that payment to a different invoice because the actual invoice that was being paid has been marked as paid into somewhere else.”
An accountant whose clients are mostly in construction, March 2026. Read it
The rule: Match only money that has landed in the bank, never a promise, and show the reason for every match so a wrong one can be found and reversed.
“bank-feed auto-match handles the easy 1:1 cases fine, but the exceptions ... still end up manual, even for people paying for tools that claim to automate this.”
A Reddit thread on payment matching, collected in August 2026. Read it
The rule: Build for the exceptions: every payment the machine cannot post goes to the specialist with its best suggestion and the evidence attached.
“A short payment is not automatically retainage.” “Do not force it into retainage to make the account balance.”
Contractor billing guidance, October 2026. Read it
The rule: Never split or label a short payment; queue it with the difference and any reason given, and let a person decide what it is.
What it costs to run
About $0.02 in model use: about 6,000 tokens in ($0.012 at $2 per million) and 500 out ($0.005 at $10 per million). About $13 a month at 630 payments, plus the runner ($20 a month, 2,500 workflow runs; this uses about 1,300: about 630 bank lines, about 630 remittance emails and 21 daily checks). Specialist time: about 2.6 minutes a payment redrawn (1.3 hours over 30), about $1 at $23.32 an hour, against about 7 minutes, about $2.70, by hand.
Estimate. The token counts, the 630 payments a month, the 1,300 runs and the 1.3 hours a day are assumed. The timed week replaces them.
The build kit
One prompt to paste into Claude, ChatGPT or any AI agent that can build. It checks the middle square before anything else, builds the map square by square, carries the 4 rules above, and has the whole build: what starts it, every step, the data, the review, the alerts, what to do when it breaks, and what to count before you switch it on.
Before you build
- It may never, on its own: Post a payment with no remittance and no approval; split or label a short payment; apply credits; write anything off or refund it; email or call a customer; or place or lift a credit hold.
- Keep with a person: Every short payment and deduction, and what it is: a dispute, money held back until a job is finished, a credit or a mistake; every payment from a payer nobody can name; every write-off, refund and credit on account; placing or lifting a credit hold; every call or email to a customer about a payment; and approving a suggested match that has no remittance behind it.
- Not yet: Posting any payment without a remittance or an exact match; applying a customer's credits on its own; splitting a short payment between invoices; labelling a deduction; writing anything off; emailing a customer by itself; and touching a credit hold.
Help me build this in my business: Matching every customer payment that arrives to the invoices it pays, and settling the ones that do not match. That means four things. Watching every channel the money comes in by: bank transfers, wires, checks, card payments, the bank's lockbox (the service that opens mailed checks). Finding the remittance, which often arrives apart from the money or not at all. Posting each payment to the right customer and the right invoices, including one payment for many invoices, partial payments, deductions and overpayments. And keeping the unapplied cash (money in the bank that is on no invoice yet) as close to zero as it can be, every day, against the bank. Before you build anything: this runs on one person's judgment, "Which invoice each unclear payment is for, and what a short payment means", held by the cash application specialist, with the credit and collections manager. Ask me whether each of these is true in my business, one at a time: 1. Every customer payment lands in a bank account the accounting system already reads. 2. Customers are asked to send their remittance to one receivables inbox. 3. Someone decides every short payment, write-off and credit hold, and the specialist knows who. If any is not true, stop and tell me which, and what I need in place first. Do not build around it. Rules from others who built this and got it wrong. Keep every one: - Post a payment on its own only when the remittance names the invoices and the amounts agree to the cent; never apply credits automatically. - Match only money that has landed in the bank, never a promise, and show the reason for every match so a wrong one can be found and reversed. - Build for the exceptions: every payment the machine cannot post goes to the specialist with its best suggestion and the evidence attached. - Never split or label a short payment; queue it with the difference and any reason given, and let a person decide what it is. The map of this system, a 3x3: - The middle square, the judgment it all runs on: Which invoice each unclear payment is for, and what a short payment means (The cash application specialist, with the credit and collections manager). It stays with a person. - The work, in the order it moves: 1. Read every deposit (runs on its own: Every bank line and lockbox file, the day it lands); 2. Find the remittance (runs on its own: The bank detail and the receivables inbox); 3. Match the invoices (runs on its own: By customer, invoice number and amount, the reason shown); 4. Post the clean matches (runs on its own: To the cent, then off the collections list); 5. Settle the unclear payments (a person does it: The specialist works the queue: every short pay and every unknown payer). - Along the bottom, what it runs on: Automation (The four triggers, the daily check and the off switch.); Measure (The share posted without a person, minutes a payment, matches changed, unapplied cash by age.); Build (Each customer's past payer names, the posting rules, the rules for short payments and held-back money.). Build the squares in that order, and keep the person's squares with a person. The working set to build from: - Trigger: A new line on the bank feed (each deposit, transfer or card batch); a lockbox file from the bank; an email arriving in the receivables inbox; a daily check at 4:00 pm of everything posted and queued that day. - Steps: On a bank line: read the payer name, amount, date and reference. Match the payer to a customer by name, then by the list of names that customer has paid under before, then by bank detail; if none, queue as "payer unknown" with the closest customers. Look for the remittance: in the bank detail, then in the receivables inbox (same amount within 5 business days, or the customer's sender address). If the remittance names invoices and the amounts agree to the cent with open invoices for that customer, post the payment and mark them paid. If there is no remittance, search the customer's open invoices for a set that adds up exactly; if exactly one set does, queue it as a suggestion with the arithmetic; if none or several, queue it with the candidates. If the payment is short or over, queue it with the difference and any reason in the remittance; never split or label it. On a lockbox file: read each check line and do the same. On an inbox email: read the remittance (body, PDF or spreadsheet), store it against the customer, and retry any queued payment it might explain. After every posting: remove the invoices from the collections list. On the daily check: tie the day's postings to the bank total, list unapplied cash by age, and list any posting the specialist changed. - Data: One record per payment: bank line ID, channel, date, amount, payer name as the bank shows it, customer matched and how (name, past name, bank detail, person), remittance found and where, invoices applied and amounts, difference, status (posted, suggested, queued, approved, changed), reason shown, who approved, minutes from landing to posted. - Review step: The specialist works the queue every morning and approves every suggestion. For the first two weeks she also reads 10 posted payments a day against their remittance. The credit and collections manager reads the unapplied cash list every Friday. - Alerts: A payment queued for more than two business days; any unapplied cash over 30 days old; a short payment over $1,000; the bank total and the day's postings not agreeing; the bank feed or the inbox not updating for a business day; and the wrong-but-green count, the postings the specialist changed after they looked clean. - If it breaks: What you see: nothing posted for a day, the queue filling with payments that used to post, or a paid customer back on the collections list. Check first: the bank feed is still connected in the accounting system; the receivables inbox still forwards; the customer's past-names list has not been overwritten. Safe fix: turn the posting step off; every payment goes to the queue and the specialist works it by hand. - Baseline to count before switch-on: One timed week by hand: payments a day by channel, minutes a clean payment and an unclear one (time it, do not ask), the share with no remittance, the unapplied cash balance each day by age, and paid invoices that reached the collections list. - Tools by name: The workflow runner n8n (Starter, $20 a month billed annually); the model Claude Sonnet 5.5 ($2 per million tokens in, $10 out); the accounting system's API for the bank feed, open invoices and payment posting (the posting names "general accounting or ERP systems"; which one this contractor runs is not public); the receivables inbox by the email provider's API. Inside the software: QuickBooks Online and Xero bank-feed matching (in the plan; Xero's Auto Bank Reconciliation, July 2026); NetSuite's Automated Cash Application (bank files, no PDF or email remittance). Standalone: Upflow's Cash Application Agent (NetSuite and Sage Intacct, priced by invoiced revenue, not published). People: Stealth Agents (from $1,600 a month, full time). It may never, on its own: Post a payment with no remittance and no approval; split or label a short payment; apply credits; write anything off or refund it; email or call a customer; or place or lift a credit hold. Keep with a person: Every short payment and deduction, and what it is: a dispute, money held back until a job is finished, a credit or a mistake; every payment from a payer nobody can name; every write-off, refund and credit on account; placing or lifting a credit hold; every call or email to a customer about a payment; and approving a suggested match that has no remittance behind it. Not yet: Posting any payment without a remittance or an exact match; applying a customer's credits on its own; splitting a short payment between invoices; labelling a deduction; writing anything off; emailing a customer by itself; and touching a credit hold. Ask me for the tools and numbers you need from my business before you start. Then build it one step at a time, and show me each step working before the next.
No one in your business holds this judgment?
Then the first step is the expertise, not the build. Konstellation, Nick's advisory firm, judges one of your jobs with you, free: what it costs today, the verdict, the bill and who owns it.
Get the verdict on one jobKnow someone doing this job by hand? Send them this page.
Free, for one email
One email opens every job and every system.
Everything on instig8.ai is free. Your email, once, unlocks all of it on this device, and you hear when the next job is out.
Unsubscribe any time.