How can a bookkeeping firm automate document collection across many clients?

Which stages of collection can be automated, and why does the reminder alone help least?

Collection is six stages, and each can be automated separately:

• Generate. Requests are created from each client's expected-document list, not written by a person.
• Deliver. Requests go to the client's recorded contacts on a schedule.
• Receive. Submissions arrive through a channel that already knows the client and item.
• Acknowledge. Each arrival is tied to its line, marked received but unconfirmed, and acknowledged to the sender.
• Chase. Reminders go only for lines with nothing received.
• Route. A confirmed document is filed to the client's period and released to the work.

Automating only the chase leaves the costly stages manual: someone still writes each request, sorts each arrival and decides whether a client is complete. A reminder that does not know what arrived chases documents already sent, which teaches clients to ignore reminders. Build the list first, then generation and intake, then closure, and the reminder last.

What goes on each client's expected-document list?

The list is the object the automation acts on, so it must be machine-readable. Each line is one document for one period, with at least its item, period, source path and a dated due point. This template for an invented monthly client adds who supplies each line and its status:

Each row is a standing definition; each period the automation creates one dated line from it, for example Operating account statement, March 2026, due 5 April.

Derive each line from the client's own recurring obligations and engagement: a transactions line and a statement line for every bank and card account the firm reconciles, connected or not; a line for each loan, payroll and regular supplier; and one for each item the engagement covers. Clients who differ in what they must and can supply get different lists. One template across a varied book sends irrelevant requests, which teach clients to ignore the ones that matter.

A list goes stale silently, so check it each period against a source that cannot thin out: every line on the client's bank and card statements. A payment to an unlisted lender, a new payroll debit or a new supplier means a line is missing; add it before the next period. Review the list whenever the engagement changes.

How is each document obtained, and which never need the client?

Classify every line by how it is obtained; the path decides what the automation does and what can fail:

Direct acquisition is the largest gain, because a document never requested is never chased. Classify a line as direct only where the provider's own documentation shows the path, and heed its limits:

• Bank and card feeds. Intuit's help page on connecting bank and credit card accounts to QuickBooks Online says that once connected, transactions appear ready for categorization. It requires being able to sign in to the bank's website and says clients must connect their own accounts; accountants cannot. It also says American Express Business accounts cannot be connected by that method, so confirm each connection before classifying a line as direct.
• Payroll. Square's undated help page on syncing Square Payroll with QuickBooks Online says payroll data is sent to QuickBooks automatically by default but can be switched to manual. Treat a Square Payroll line as direct only while automatic sending is on, and another provider's payroll only where its own documentation shows a sync.
• Vendor sources. Intuit's page on connecting an Amazon Business account to QuickBooks Online has the user sign in to QuickBooks as an admin, then to Amazon Business as the primary administrator. It says the app cannot connect a personal Amazon.com or Amazon Seller account, and that the connection expires every once in a while and must be reconnected by a primary admin or company admin, so treat only Amazon Business purchases as direct and send a lapsed connection to the client's admin.
• Merchant document forwarding. Dext's help page on email forwarding rules has the client set a rule in its own mailbox that forwards suppliers' emailed receipts and invoices to Dext automatically, and suggests adding supplier email addresses to the rule's conditions. A supplier the rule does not match is never forwarded, so check forwarded receipts against every card and bank statement line, not against what arrived.

Intuit's page on connecting bank and credit card accounts describes the connection as automatically downloading the latest transactions and does not mention statements; with no documented direct path, classify statements as requested from the client. So reconcile each account against the bank's own statement for the period, never the feed alone: a feed that drops, duplicates or misdates a line, or stops while a connection is down, agrees with the books it populated.

Still request from the client: bank and card statements, including for connected accounts; contracts and loan papers; receipts for cash spending; and explanations a feed cannot give.

How does the chase stop the moment a document arrives?

The chase must know what arrived, which needs a link between intake and the list. Every request carries its line (client, item and period), and a submission against a request lands on that line. An arrival that cannot be tied to a line goes to an exception queue and closes nothing.

Karbon's help page on sending client requests says a client can mark a request complete, and that once all the client requests have been completed, no other reminders are sent. A client's mark is its own statement, not proof the expected document arrived. So give each line three states: open, received but unconfirmed, and closed. Reminders stop at received; the line closes only when the document is confirmed as the one expected for that client, account and period, and otherwise reopens with a request naming what is missing.

What escalation sequence should run, and where does it end?

Fix one sequence, running without anyone starting it:

1. The request goes out a set number of days before the due point.
2. A reminder goes out at the due point for each open line.
3. Further reminders follow at a fixed interval for a fixed number of rounds.
4. A final automated notice goes to a second contact the client named at onboarding.
5. At the terminal step, each open line becomes a task for a named staff member, dated before the firm's own work for that period must start.

A direct line still open at its due point becomes a request to the client to reconnect the source or restore the rule, since the client makes those connections, and then follows the same sequence to the terminal step.

Karbon's help page on sending client requests says the reminders auto-sent for a single request stop after the fifth. Whatever a platform does when its reminders stop, the terminal step hands each open line to a person by date.

A missing line ends one of three ways:

Decide the third outcome before the work-start date, so the client sees the gap rather than discovers it. A client who never responds reaches the terminal step on every line at once, so the named person deals with the client as a whole.

How should intake attribute each document to the right client and period?

Attribution by a person at intake is the hidden per-document cost, and a wrong one puts one client's document in another's file. Make the channel carry the identity:

• Per-request upload. A submission against a request inherits its client, item and period.
• Per-client address. Loose documents go to an address or portal belonging to that client alone, never a shared firm inbox.
• Known senders. Each client's permitted senders are recorded, and a submission from anyone else goes to the exception queue.

Dext's help page on email forwarding rules says each Dext account has an account-level address that anyone can use to submit documents, separate from each user's own address, and that documents forwarded there show no owner. Where a firm gives each client its own Dext account, that address identifies the client; the page does not describe that arrangement, so confirm it from Dext's own documentation before relying on it. The page does not say whether the sender's address is recorded for those documents. Apply the known-sender check there only if the product shows the sender; otherwise confirm each arrival by content against an open line and send only arrivals that match no line to the exception queue. Match loose arrivals to an open line by account and date range. Designing the intake standard is a separate question on standardizing document intake.

Where several people at one client send documents, record each at onboarding; anything from an unrecorded sender waits in the exception queue for a person to decide. Confirm by content, not sender: a statement from the right person still fails if its account or dates do not match the line.

What should one view across the whole book show?

Build one view from every client's list showing each line not yet closed, with these fields:

• Client, period and item
• Whether the line is open or received but unconfirmed
• Source path and due point
• Days past the due point
• Escalation position, and the owner after the terminal step
• The date the firm's work for that client and period should start

Build it from the lists, never the inbox, where a missing document leaves no trace. Direct lines belong in it too, because a stalled connection or a stopped forwarding rule is a missing document no one was asked for. Staff then work the exceptions instead of opening each client in turn, so give that queue a named owner and a backup for every working day.

How do clients join the flow, and what about one who will not?

Bring each client in this order:

1. Build its list from the engagement and its accounts, and classify each line's path.
2. Have the client make each direct connection and forwarding rule itself, and record each.
3. Give the client its intake address or portal link, record its permitted senders and a second contact, and explain what a request is.
4. Run the first period with a person checking that every line closed against the right document.

A client who will not use the flow keeps its list. Its requested lines move to the obtained-by-a-person path, with a named owner and the same due points, so they stay in the outstanding view and the record. Whether the engagement changes is a separate question on getting clients to send documents on time.

What constraints must the automation satisfy?

Automation multiplies the reach of one mistake, so build it around three controls of your own; which obligations bind the firm itself is a separate question:

• Separation between clients. Every request, address, portal and stored file belongs to one client, staff see only the clients they work on, and an unmatched or unconfirmed arrival is held, not guessed. Only the exception-queue owner and backup see arrivals not yet tied to a line, and each queued item keeps the client of the address or request it came through. Treat a document sent or filed to the wrong client as an incident and start the firm's incident response at once.
• Recorded authorization for each direct source. Record what each connection or forwarding rule covers, who at the client set it up and when, where its data lands and which firm staff see it, and review that record on a set schedule. On the day the engagement ends, remove the firm's access to the client's systems, have the client turn off every rule forwarding to an address the firm holds, and have the client confirm from its own settings that both are gone.
• A record of what was requested and received. Keep, for each line, every request and reminder (date, recipient, wording) and every arrival (date, sender, line closed, who confirmed it). How long to keep it is a separate question.

The FTC's guide to its Safeguards Rule says coverage turns on the activities a business undertakes, not how it is categorized, and lists tax preparation firms among the Rule's examples of financial institutions. It does not settle whether a firm that keeps books but prepares no returns is covered, so establish whether the Rule covers the firm before relying on its not applying. The guide also says the FTC has exempted financial institutions that maintain customer information concerning fewer than five thousand consumers from certain provisions of the Rule, without naming them, so a covered firm below that number should establish which of the safeguards below apply to it. For a covered firm, the guide's safeguards that bear most directly on this automation include:

• Determine who has access to customer information, and reconsider regularly whether they still have a legitimate business need for it.
• Encrypt customer information on the firm's system and in transit, or, where that is not feasible, use effective alternative controls approved by the Qualified Individual who supervises the information security program.
• Where the firm uses third-party apps to store, access or transmit customer information, implement procedures for evaluating their security.
• Implement multi-factor authentication for anyone accessing customer information on the firm's system; the only exception is another equivalent form of secure access control that the Qualified Individual has approved in writing.
• Select service providers with the skills and experience to maintain appropriate safeguards; the firm's contracts with them must spell out its security expectations, build in ways to monitor the provider's work and provide for periodic reassessment of their suitability.
• Monitor when authorized users access customer information on the firm's system, and detect unauthorized access.
• Create a written incident response plan.

How do you measure whether it worked?

Measure from the lists every period:

• Aging. Count open lines by days past their due point, by client and across the book, and count received-but-unconfirmed lines separately.
• Work-start lag. Measure the days from period end until every line a client's work needs has closed, against the planned start.
• Path mix. Track the share of lines obtained directly.
• Touchless matching. Track the share of arrivals tied to a line without a person.
• False chases. Count reminders sent for items already received, which should be zero.
• Terminal outcomes. Count lines that reached a person and lines marked unobtainable.

Suppose a firm's 60 clients carry 900 lines a month: 480 direct, 360 requested, 40 produced by the firm and 20 obtained by a person. Before automation its work started, on average, 15 days after month end. Two months in, 331 of the 360 requested lines close before the terminal step and 29 reach it, 3 of them marked unobtainable; 6 lines stay open more than five days past their due point, and work now starts 8 days after month end, 7 days earlier. Rising aging or any false chase is the early sign of degradation.