Receipts sent over chat arrive with no client, no period and no context

The image is fine. What is missing is everything around it: which client sent it, which of their entities it belongs to, and which period it falls in. Chat platforms deliver a photo and a phone number, and a phone number is not a client record. Firms respond by pointing better extraction at the picture, which reads the merchant and the total accurately and still cannot say whose books it belongs in.

This page assumes the client will not stop. Telling an owner who sends 30 photos a quarter from a delivery van to log into a portal instead is a policy with a known compliance rate of roughly nothing, so the practical question is how to make an unattributed stream into filed records without a junior retyping context onto every image.

Measure the unattributed bucket, not the message count

The number that matters is the share of chat-sourced images that land somewhere no engagement can see, and how long they stay there. Message volume tells you nothing; a firm receiving 400 images a month with 5% unattributed has a smaller problem than one receiving 80 with half of them stranded.

1. Take 1 month of chat-sourced images across every number the firm uses, including handsets staff use personally for client contact.
2. Classify each into 3 buckets: attributed to client, entity and period automatically; attributed after a human touched it; never attributed.
3. Record the time from arrival to attribution for the middle bucket. A median above 1 working day means the client is being asked questions about a receipt they have already forgotten.
4. Split the never-attributed bucket by cause — unknown number, known number with more than 1 entity, no period signal, forwarded image — using the 5 causes below.
5. Count the images that arrived on a staff handset and never reached firm storage at all. This is the number that will be uncomfortable, and it is the one that matters most.

Five reasons a chat image cannot be filed

In order of how much volume each carries in a typical practice. The first 2 are identity failures, the middle 2 are context failures, and the last one is not a data problem at all.

Bind the number to an entity before the first receipt

Binding is a 1-time step and everything downstream depends on it. When an unrecognised number sends its first image, the system should reply immediately with a link that identifies the sender against a client and, where the client has more than 1 entity, against a specific entity and role. The image waits in a holding lane, attributed the moment the binding completes, and the client learns the rule at the only moment they are paying attention.

• Bind to entity, not to client. A group with 3 trading companies and a property company needs 4 destinations, and the owner's handset is 1 number.
• Record the role. A driver sending fuel receipts, a spouse sending purchase invoices and the owner sending everything are different senders with different default expectations.
• Re-confirm on a schedule and on change. Numbers move between people, and a stale binding files 1 business's receipts into another's ledger.
• Handle the multi-entity case explicitly. Ask once per session rather than once per image, and make the answer sticky until the client switches it.
• This is the same idea as making the address the routing key in email — a per-client forwarding address that files attachments to the right period — applied to a channel where the identifier is a phone number instead.

The period the photo does not carry

A photo carries a capture timestamp, and chat platforms re-encode images for transport, so even that often does not survive. More importantly, the capture date is the wrong field: a client photographing a shoebox in July is sending 40 receipts spanning 6 months, all timestamped July, and the document date on the receipt is the only real signal — which is itself missing on faded thermal paper.

• Prompt for period at capture, defaulted to the open period on that entity. 1 tap on a default that is right most of the time beats a field nobody fills.
• Treat a burst as a session. 12 images in 90 seconds is 1 batch with 1 period answer, not 12 questions, and splitting a burst into documents has the same boundary problem as a batch scan that splits into the wrong documents.
• Flag straddles rather than guessing. An image arriving after a period is closed, with a document date inside it, is a reopening decision for a person to make.
• Ask for the outstanding item, not for receipts in general. A prompt naming what is actually missing converts better and arrives pre-attributed — the list-generation approach in generating the next request list from the last close.
• Move the request item on capture, so the outstanding board reflects reality: it only means anything if its states are honest, which is the argument in an outstanding-items board that says complete but is not.

Personal handsets, and the records that never reach the firm

The largest version of this problem produces no data at all. A client messages a manager's personal number because that is the number they have, the manager screenshots what matters into an email when they get to it, and the rest stays on a handset the firm does not control. Nothing is in the engagement store, nothing is in any queue, and the leak is invisible to every measurement above except the last step of the count.

The order to build it in

1. Stand up 1 firm-controlled number and publish it. Nothing else works while client traffic is spread across personal handsets.
2. Build binding and the holding lane. An unbound number gets an automatic reply and a link, and its images wait rather than disappearing.
3. Add the period prompt with an open-period default, and make a burst 1 question rather than many.
4. Wire capture to request-item state, so the outstanding list and the chase both move without a human step.
5. Only then improve extraction. Reading the merchant and total off a good photo is the easy part, and it is worthless while the image cannot be attributed.

Image quality is a separate discipline with its own guidance, and it is worth doing after attribution rather than before. The work here is ordinary integration and state handling — a messaging webhook, a binding record, a holding lane and an item-state update — which we build as AI agents and workflow automation for accounting, tax and bookkeeping firms, on top of the intake model the rest of the client intake, chasing and portals cluster sets out. If you are weighing whether to build or buy this, the questions worth asking a supplier are in choosing an AI development partner.

• chat intake
• receipt capture
• attribution
• practice operations