Records emailed to a staff member never reach the engagement folder

The document is not missing. It is 4 messages down a reply thread in a manager's mailbox, attached to an answer about something else, and the intake system never saw it because intake only watches the address clients were told to use. Meanwhile the outstanding-items list still says the statement has not arrived, and the preparer chases a client who already sent it — the single fastest way to lose a client's willingness to respond at all.

This is a routing failure with a specific shape, and it is worth separating from the general "clients email us things" complaint. A firm can have excellent intake on its front door and lose a material share of records through side doors that look like ordinary correspondence.

Reconcile the mailboxes against the engagement store

Nobody can estimate this leak by feel, because every instance of it is invisible to the person who would notice. The measurement is a set difference, run over 1 closed period so the answer is not moving while you count it.

1. Choose 1 period and 10 clients, mixing a couple of files that felt painful with a few that felt smooth. A smooth engagement with a large gap is the most informative result you can get.
2. Enumerate inbound mail from each client's domains across every firm mailbox for the period, including personal staff mailboxes, not only the intake address.
3. Count real attachments per message: files with a filename and a content type that is a document or an image, excluding anything referenced inline by the HTML body.
4. Enumerate documents filed to each engagement for the same period, with their source channel recorded.
5. Diff the 2 sets on client, period and document identity. Anything received and not filed is the leak; anything filed twice from different channels is the duplicate problem hiding behind it.
6. Classify each miss by the 5 causes below. The distribution decides which fix is worth building first.

Five ways an attachment arrives and is never filed

Ranked by volume in a typical practice. The first cause usually dominates, and the last 2 are the ones that make a client insist they sent something when your mailbox genuinely holds nothing.

The reply thread addressed to one person

Clients reply to whoever last wrote to them. A manager asks about a director's loan, the client answers and attaches 3 bank statements while they have the file open. The thread began as correspondence, so nothing about it says intake, and no rule watching the intake address will ever see it.

• The mailbox that receives is not the mailbox that was advertised. Any capture design that only watches 1 address is designing for the client you wish you had.
• Holidays and handovers make it worse. Records attached to a thread with a staff member who is away sit unread for the length of their leave.
• Leavers make it permanent. When a mailbox is archived, its unfiled attachments leave with it, and nobody discovers the gap until the next period is prepared.
• This is not a case for a per-client forwarding address, which solves a different problem well — give every client a forwarding address that files itself covers that design. It only works for clients who use it.

Nested forwards, pasted images and links that expire

The remaining causes are format problems, and each one defeats a parser that only reads the obvious part of a message. A forwarded chain arrives as a message inside a message; the statement is a part of the inner one, so a parser reading top-level parts sees a single item and no documents.

Size limits produce the strangest version. Google states that the sending limit for personal Gmail accounts is 25 MB, that administrators set their own limits for work accounts, and that Gmail converts oversized attachments into Drive links automatically. From the client's point of view they attached the file. From yours, a message arrived with 0 attachments and a URL that may be scoped to their account, may expire, and will certainly not survive being forwarded to a colleague.

• Recurse into embedded messages when parsing, and record where in the nesting a file was found. It matters when a preparer asks where a document came from.
• Treat a body that mentions attaching alongside 0 attachments as a defect to action the same day, while the link is still live and the client still remembers.
• Keep the original message with the file. Provenance — who sent it, when, on what thread — is what makes a captured document defensible later.
• Capturing the file is only half of it. A statement that arrives as an unreadable scan or a password-protected PDF is captured and still unusable, which is the problem in half the client statements will not open.

The capture rule: client domain plus engagement token

The rule has to be broad enough to catch reply threads across every staff mailbox and narrow enough that it never files a partner's personal correspondence. Two keys do most of the work, and neither depends on the client doing anything differently.

1. Match the sender against known client domains and known contact addresses, including the external bookkeepers and spouses that a real client relationship involves.
2. Look for an engagement token on the thread — an opaque reference the firm puts in the subject or a header when it starts a conversation, which survives replies and forwards.
3. Require a candidate document: an attachment, or an inline image above a size floor, or a share link. No document, no capture.
4. Route a domain and token match straight to the engagement and period. Route a domain match with no token to an unmatched lane with a suggested client, for a person to confirm in seconds.
5. Record the capture against the request item, so the outstanding-items list moves the moment the file lands rather than when someone gets to it.

That last step is where firms typically stop too early. A file captured into a store, with the request item still showing outstanding, buys nothing: the preparer still chases, and the board still lies. Item state has to move on capture, which is why the states themselves have to be honest — the argument in the outstanding-items board that says complete while the preparer is still waiting.

What the rule must never do

• Never capture from a staff mailbox indiscriminately. Match on client domain first; a mailbox-wide sweep will file personal, HR and recruitment mail into client engagements.
• Never file to a group's wrong entity. A client domain shared by 3 companies needs the token or a human, because a misfiled statement is worse than an unfiled one.
• Never delete or move the original. Capture copies; the mailbox stays intact and the staff member's workflow is untouched.
• Never let the unmatched lane grow unowned. A capture rule with a queue nobody clears reproduces the original problem with an extra system in it.
• Never assume the client will change channel. Chat is the other side door, with its own attribution problem — receipts sent over chat arrive with no client and no period.

Done properly, email capture also removes the argument about portal adoption, because the portal fills whether or not the client ever signs in — the bridge approach in moving email-only clients onto a records portal. It is ordinary internal plumbing rather than anything clever, and it is the kind of thing we build as internal tools and ops automation for accounting, tax and bookkeeping firms, alongside the request-list and state model the rest of the client intake, chasing and portals cluster specifies.

• email intake
• document capture
• engagement files
• practice operations