A bookkeeping mailbox runs on its own logic, different from a tax practice’s. The same job runs twelve times a year, for every client at once. Almost nothing arriving in it is worth a message on its own. A large share of it was never written by a person. Those three facts decide most of how the pile gets worked.
- Nothing here finishes. A return gets completed and it’s gone. A set of books rolls into the next month carrying whatever didn’t get settled, and an item left open doesn’t stay one item.
- The economics run the opposite way from tax work. A single query costs more to send than its answer is worth. Only the batch pays, so when you ask becomes a design decision rather than a habit.
- Most of the volume is machinery reporting on the client’s systems. Nearly all of it asks nothing. The few that matter say something has stopped, and they arrive in an identical envelope.
- You hold half a record. The accountant at the other end holds the other half, and their date is the only one in the arrangement that anybody outside it treats as real.
Twelve of everything, and nothing closes
Take a tax practice and a bookkeeping practice of the same size. The difference is concurrency.
A preparer with two hundred clients has one substantial job per client per year, and it arrives in waves. On an ordinary June morning most of that client list is asleep. A bookkeeper with twenty-five clients has twenty-five live engagements every day of the year. Each one produces transactions, questions, documents and system noise, continuously. Twenty-five is a comfortable number of clients and an uncomfortable number of open jobs. That’s why a bookkeeping mailbox feels heavier than its client count suggests it should.
The second difference is that the work carries on. A return gets filed and the file shuts. A month-end gets signed off, and the next one has been accumulating for four weeks already. The list is never empty and you’re never between jobs, so anything unresolved has somewhere to go: forward.
That’s where the real damage sits. An unanswered query in a tax practice holds up one return, and announces itself by doing so. An unanswered query in a set of books holds up nothing. The month closes anyway, with the item sitting in a suspense account or coded to a best guess, and the next month closes on top of it. By the fourth month there are eleven of them and they’re past answering. The person who finds them is you, in a panic in November, or somebody else entirely at the year end. A five minute question in February is a reconstruction in December, and year-end close and the inputs you cannot get in March is where that bill arrives.
The third difference is the one that runs in your favor, and it’s large enough to organize a practice around.
The cycle repeats, so every improvement you make to it is made twelve times. A tax practice that redesigns the way it asks for documents gets one use of that work per client per year. Fix the shape of the monthly query message, or the moment in the month it goes out, and you collect in February, again in March, and again for as long as the client is a client. The arithmetic runs the other way too. A clumsy arrangement is a standing charge.
This is also the one place in a practice where reading the mailbox against a list is genuinely cheap. Running the firm inbox makes the general case that a practice knows what it’s waiting for before the client sends anything. In bookkeeping it’s the same list every month. The statements, the feeds, the card receipts, the payroll changes, the queries outstanding. You write it once and reuse it, which almost nothing else in accounting allows, and a firm that’s never written it down rebuilds it from memory a hundred and eighty times a year.
A tax practice meets that compression for ten weeks. A bookkeeping practice meets a ridge of it in the first two weeks of every month. What that does to how you decide what goes first is inbox zero during busy season, and it reads the same at monthly frequency with a shorter runway.
The item is smaller than the message about it
Here’s the economics of a bookkeeping query, written out. Most of the correspondence problems in this job come from ignoring it.
A card payment appears in the feed with a merchant name that means nothing. To settle it by email you write a message. The client reads it on a phone, thinks, and replies with half an answer. You read the reply, go back to the transaction, and code it. That’s about ten minutes of two people’s attention, spent on a line that won’t change any figure anybody reads.
Per item, that never works and it never will. In aggregate it works fine, because forty of those lines are the difference between a set of books and a rough idea. The whole craft of bookkeeping correspondence follows from that gap. The value is in the batch, so the batch is the only unit worth sending.
Building the batch itself is already covered properly, so this page leaves it alone. Cut the list inside your own office before it leaves. Split the lines a client can answer from memory from the ones that send them to a drawer. Propose an answer wherever being wrong changes nothing. Say at the top which few lines actually matter. All of that is in year-end close, and it holds at monthly frequency. What changes at monthly frequency is everything around the list.
Three things, and firms are most surprised by the first.
Give the batch a fixed slot and keep it there. Queries on the twelfth of every month, whatever else has happened. Bookkeeping is about the only job in a practice where this works, because the job repeats often enough for a client to form a habit around it. A client who gets your questions on the twelfth learns that the twelfth is when they deal with you. Nobody has to tell them. After four or five months they start answering the same day. A client who gets questions whenever their file reaches the top of your pile has nothing to learn from. The gain here is speed. A habit answers faster than an intention, and habits need a rhythm to form on.
Decide in advance what happens to a line nobody answers. Write the position down once, so it stops being a monthly judgment. There are three answers available. Code it to a stated default and note that you did, park it in suspense, or hold the close. Every practice has a preference and most have never said it out loud, so the client gets whichever one the person doing the work felt like that afternoon. Say it once, at the start of the engagement, and it stops being a negotiation forty times a year. Onboarding a new tax client makes the general argument for settling this class of thing in the first weeks, when it costs nothing.
And write down the amount below which you stop asking. Every bookkeeper has one and almost nobody has stated it. An unstated threshold drifts with mood and workload, and it’s hard to explain to a client who asks why one small payment got a question and another one didn’t. A stated threshold, agreed with the client, is the fastest way to shorten a monthly query list. It’s also the only one that gets easier every month.
What a client can still remember
Bookkeeping queries go stale in a way tax queries don’t. The reason is structural, and it has nothing to do with how diligent you are.
Most tax questions point at a document. A statement, a form, a certificate, a completion letter. Documents keep. Ask in July for something issued in February and it’s as obtainable as it ever was, just more annoying to fetch, which is the subject of managing client document requests.
Most bookkeeping questions point at a memory. What was this payment for. Why did this transfer go out. Is this the deposit on the van or something else. Often there’s no document anywhere, because the event was somebody buying something small on a Tuesday. The only record sits in a person’s head, and it decays fast. Within two weeks the answer is easy and accurate. At three months it’s a guess. At six it’s a guess offered confidently, which is worse. It arrives looking exactly like a fact and goes into the ledger as one.
So lateness in this job is a quality cost as well as a scheduling one. It’s invisible too, because a bad answer and a good answer are the same length.
That sets the real deadline on the query batch. While the month is still recent, earlier than the close and earlier than the year end. Where you can see a client’s records as they happen, the cheapest query you’ll ever raise is the one raised in the week the transaction landed. The client answers from the last thing they did, instead of from an archaeology of their own card statement. Raise a few during the month and send the rest on the twelfth. Some lines have a shelf life shorter than your cycle.
The other half of decay is knowing when to stop. A line asked three times won’t be answered on the fourth, and the fourth ask spends goodwill you’re going to need for something that actually matters. Past that point, the honest move is your stated default. Apply it, tell the client in one sentence what you did and why, and invite a correction. That turns an open item that will never close into a closed item that’s probably right and certainly visible. It also puts the decision in front of the one person who could still overturn it.
The answer that should have been a rule
Every query you get answered has two possible futures. It’s a fact about one transaction, or it’s a standing instruction. Most of them are the second and get treated as the first, and that single error accounts for a great deal of the length of a monthly query list.
The tell is easy to check. Take a client you’ve had for eight months. Count the queries in month one against the queries in month eight. On a stable business those numbers should be falling steeply. If they’re flat, nothing you’ve been told is being kept, and you’re spending the same ten minutes over and over on information the client already gave you.
What happens is ordinary. A client explains that the recurring payment with the meaningless merchant name is the yard rent. The explanation goes into a reply. The reply gets read, the transaction gets coded, and the reply goes into an archive. Next month the same payment appears. The person coding it may not be the person who asked, and has no way to know the question was already settled. The answer existed. It was filed in the mailbox, which is a record of what arrived.
So the rule is short. The mailbox is where an answer arrives. Answers live somewhere else.
Where they live depends on your ledger. Most accounting packages hold a coding rule against a payee, and that’s the right home for anything that will recur, because it acts on the next transaction without anybody remembering. The rest is most of the value, and no ledger holds it:
- the split that applies to that particular vehicle
- the person who actually answers
- the supplier whose invoices always arrive a month after the payment
- the two categories this owner cares about, and the twelve they ignore
- the transfer that looks alarming every quarter and is fine
Those are facts about a client. They stay true for years, and they belong in a note against the client that whoever picks the file up next will read.
One honest limit. A rule is a decision, so it can be wrong, and it goes on being wrong quietly in a way a query never does. A business that changes what it does starts generating transactions that the old rule swallows without comment. So read the list of standing rules for a client once a year, at the point where you’re already thinking about that client, which is the close.
The same recurrence runs on the inbound side. Clients ask the same questions every month too, and mostly they’re asking because nothing told them. Where we are, whether the filing went out, whether payroll is done. Stopping client questions from piling up covers what to do with a question that keeps coming back. What’s specific here is that a monthly cycle makes the repetition predictable, so it can be answered before it’s asked. Send a short fixed message at the same point each month, saying what’s done, what’s outstanding and what you’re waiting on. That removes a category of inbound mail that better replying would never touch.
The mail that nobody wrote
Open a bookkeeper’s inbox next to a tax preparer’s. The visible difference is the machines.
Feed notifications. Statement ready notices. Digest mail from a receipt capture app. The payroll platform. Portal invitations. Bank security notices. Subscription receipts for tools that belong to the client rather than to you. The ledger’s own alerts about things it has done. On a busy day that layer can be most of the pile by count, and nearly all of it is a record rather than a message. A statement ready notice exists so that a search in nine months can prove the statement was available. Filing it is correct. Reading it is wasted time, and deleting it costs you the record.
Hidden inside that layer is the most time critical mail you get.
A bank feed that stopped. An authorization that expired and needs the client to sign in again. A declined card that funds a payroll subscription. A filing that came back rejected. A scheduled payment that didn’t go. These arrive in the same format, from the same senders, with subject lines built by the same template, and their consequences are the largest in your month.
One test separates them cleanly, and the wording won’t give it to you. The messages that matter announce that something has stopped. The rest confirm that something happened. A message about an event is a record. A message about an interruption is work.
The interruption class is expensive because it breaks quietly by construction. A feed that dropped on the sixth leaves no visible gap, because a missing transaction leaves no mark. You find it on the third of the following month, when the file won’t reconcile. Now you’re doing a manual import, re-checking a period you’d already closed, and asking a client for a statement you should never have had to ask for. The alert existed. It arrived on the sixth, between a digest and a receipt, and nobody read it.
Three things help, and one caveat sits underneath all of them.
Treat the interruption senders as their own category, with their own rule, apart from everything else a machine sends. There are usually fewer than a dozen of them across a whole client list, and you know them in advance. The feed provider, the payroll platform, the filing service, the capture app. Anything from those senders gets looked at. Everything else in the machine layer goes somewhere searchable and stays unread.
Decide, per client, which of their operational notices should come to you. Most practices never do this, which is why the expiring card notice goes to an owner who ignores it. Add your address to the alerts that concern the books while you’re already setting the client up. That turns two weeks of quiet breakage into a message on the day.
And check the thing itself. Here’s the caveat: some breakages send no mail at all. A feed can simply go quiet, so the first two aren’t a control on their own. The reliable check is the date of the last transaction on every feed, once a month. It takes a few minutes across a whole client list, and it catches exactly the failures the mailbox can’t show you.
The forward with nothing written above it
A large part of a bookkeeping inbox gets pushed at you. It arrives without being addressed to you in any meaningful sense.
A supplier invoice forwarded by the client’s office manager with no text above it. A chain fourteen messages long with “see below” at the top. A photograph of a receipt taken in a van, sent with “for the books”. A supplier who got your address two years ago and now copies you on everything they send anybody. The client’s own subscription confirmations, arriving because somebody once set your address as the billing contact.
An unmarked forward is ambiguous between at least four different asks. The sender knows which one. You don’t. Pay this. Code this. File this. Answer this. They all look identical, and the cost of guessing wrong runs one way. File something that needed paying and you have a late payment. Pay something that needed filing and it’s worse.
There’s a second loss. The forward strips the context that made it mean something. Whatever the office manager knew when they pressed the button stays in the chain above, or in their head. The attachment is called scan_0031.pdf.
The repair is a default rather than a convention, and the difference matters. A convention asks people to remember something. A default decides what happens when they forget.
Say once, in writing, how an unmarked forward gets treated. Coded and filed, and nothing else. Then anything that needs payment or a reply has to say so in one line at the top, and the cost of resolving the ambiguity falls on the only person who can resolve it cheaply, which is the person who already knows the answer. Clients accept this readily. It’s one sentence, it’s obviously reasonable, and it holds up far better than asking them to categorize things.
A dedicated address for this class of traffic is worth more here than anywhere else in a practice. Running the firm inbox makes the case for naming the address that holds the record for a client, and notes correctly that clients will go on replying to whoever wrote to them last. Most of this pile sits outside that objection. Suppliers, capture apps, billing systems and a client’s own accounts software send wherever they’re configured to send. They’re configured once, and they comply forever. The address rule works perfectly on the mail that came from a machine, which here is the majority of it.
Then there’s the duplicate. The same invoice reaches you three times. Once from the supplier, once forwarded by the client, once through the capture app. Bookkeepers reliably try to solve this one in the mailbox, and it’s worth being blunt: a mailbox can’t be deduplicated reliably, so don’t try. The defense against posting or paying something twice sits at the point of entry into the ledger, where the document number and the amount get checked against what’s already there. The mailbox is where things arrive. The ledger is the register of what has been dealt with. Most of the anxiety in this part of the job comes from treating the first as the second, and no amount of foldering fixes it.
When those invoices are your own rather than a client’s, the pile behaves differently. It has a page of its own in supplier and software invoices in the firm’s own inbox, including what to do about the fake ones.
The messages that move money
Bookkeepers sit on the payment path. That changes which parts of the mailbox can be casual.
Two kinds of message live here, and only one of them is safe in email at all.
The first is authorization. Somebody approves a payment run by replying, and that reply is the entire audit trail for money leaving a business you don’t own. Two things follow. The approval travels with the run rather than staying in a thread, because in eleven months the question will be who authorized this, and the answer needs to be a document rather than a search. And the approval carries the quantity. A reply saying “yes, go ahead” above a quoted message leaves what was agreed to wide open. The version that survives names the total, the count and the payment date. The cheapest way to get it is to put those three things in your own message, so that agreeing to it is agreeing to them.
The second is any instruction that changes where money goes. A supplier writing to say their bank details have changed. A new account for an existing payee. An urgent request from an owner who’s traveling. This is the one class of message in the whole job that has to leave email to be settled, and the rule is one sentence. Confirm it on a number you already held, never on a number contained in the message. The message is the thing under suspicion, so nothing inside it can be used to check it.
The bookkeeper gets targeted ahead of the owner, and the reasons are all structural. You process a high volume of payment paperwork with your attention on coding rather than on plausibility. You have authority to move money that isn’t yours. And you sit outside the business, so a change in routine looks ordinary to you where it would look strange to somebody who sits ten feet from the person supposedly asking.
The arrangement that holds gets written down at the start. Who can authorize what, up to what amount, through which channel, per client. The value of having written it is that it gives you something to point at on the afternoon you decline to do something. That’s the part that is genuinely hard, when the person asking is annoyed and in a hurry.
The dates that do not move
Most of a bookkeeping month is internal. The date you close, the date you send queries, the date you promised a management pack. Those are yours, and a client can tell, which is why they get answered at the speed preferences get answered. Year-end close has the proper treatment of what to do with a date your own firm invented.
Payroll is different. People get paid on a day, the day holds, and missing it is the one failure in this job that everybody notices immediately.
Its shape in the mailbox is specific. There’s a fixed cutoff, and there’s a set of inputs that arrive from the client’s staff, late, in whatever format was to hand. Three of those inputs cause nearly all of the trouble.
The change that arrives after the run. Somebody left on the fourteenth and you hear on the third of the following month. The correction is several times the work of the original, and it concerns money that has already gone. That makes it a conversation as well as a task.
The instruction that arrives as conversation. “Sarah’s going up to four days from next month” turns up in the middle of a reply about something else entirely. No attachment. No mention of payroll. It’s the highest consequence sentence in your month, and it looks like small talk in a thread about a supplier statement.
And the silence, which is genuinely ambiguous. A client who stays quiet before a payroll cutoff either has nothing to change or hasn’t looked, and both of those arrive as the same message.
One fixed message before every cutoff handles all three, and what makes it work is that it asks for a nil return. Are there any changes this period, and if there are none please say so. A reply saying nothing has changed is a fact you can run payroll on. Silence stays silence, the same way silence on a set of draft accounts stays short of an approval, and the payroll version of that problem arrives twelve times a year rather than once. Because it recurs, the message is worth writing properly once. It’s the highest return template in a bookkeeping practice.
Pair it with a short confirmation afterwards. What was run, for how many people, at what total, paid on what date. That message costs a minute, and it settles the standing monthly question about whether payroll went.
The other fixed dates in the month behave the same way with a longer wavelength. A sales tax filing, a pension submission, a periodic return the books feed. Those dates are known a year in advance, so they live in a calendar. What belongs in the mailbox is the input that has to arrive before each one and the confirmation that has to go out after it. Where a client is also paying their own estimates against a tax bill, that run is a different job with a different owner, and it’s quarterly estimate reminders and the silence that follows.
The accountant at the other end
Almost every bookkeeping engagement has a second professional attached to it, and the two of you hold half a record each. You have the transactions and the client’s day to day. They have the return, the judgments and a filing date that a tax authority set. The client holds a contract with each of you, and the two of you hold none with each other. That small fact has large consequences for how the correspondence should run.
Three problems account for most of what goes wrong between the two mailboxes.
The relay. Their queries land with you, and perhaps half of them are answerable only by the client. Pass each one on and pass the answer back, and every question grows a week. It arrives at its destination third hand, paraphrased by somebody who wasn’t sure which part mattered. Agree the rule explicitly. If the answer is in the records, you answer it and they never trouble the client. If the answer is in the client’s head or in the client’s drawer, the question goes straight to the client from whoever has the standing to get a reply, and the other one is copied. This arrangement dies when nobody states it, because then both of you assume the other is asking. The accountant’s version of that discovery is in managing client document requests, which notes that the chronic non-responder in a chain is often the bookkeeper waiting on somebody else entirely.
The adjusting journals. These come back from the accountant as an attachment in an ordinary message. Leave them unposted and next year’s opening balances are wrong, and nobody finds out for a year. It’s the quietest failure in the whole relationship, and its cause is entirely presentational. The message looks like the end of a conversation when it’s actually the start of a task. A confirmation going the other way fixes it. Posted on this date, and the trial balance now agrees to yours. That message is worth far more than its length, because it’s the only moment in the year when two separate systems are known to agree, and without it nobody can say when they last did.
Both of you writing to the client in the same week. The client receives overlapping requests from two firms, and the ordinary human response is to answer one of them and assume it covered both, or to answer neither. That’s a scheduling problem. You solve it once a year, in the handover conversation, by deciding who asks for what.
Which brings up the handover itself. The message that ends a bookkeeping year and starts a tax one is covered as a close in year-end close. The part specific to this direction is what goes missing from it. Firms send the file, the trial balance and the date the books were closed. They leave out the list of queries that were never answered and the items that carry a stated default rather than an answer, because sending it feels like an admission. Send it anyway. It’s the most useful page in the pack, and it’s the only warning the accountant will get about which figures are soft. Hold it back and the softness relocates into somebody else’s return.
If you’re reading this from the other side, as the accountant rather than the bookkeeper, the practical summary is short. The bookkeeper is the fastest responder in the chain and the one with the least standing to compel anything. Send them what the records can settle, and send the client what only the client knows. Ask for the unanswered query list rather than waiting to discover it. And confirm that your journals were posted, because assuming they were is the reason opening balances go wrong.
Point in a month that repeats
All of the above runs without software. Bookkeepers ran it on a day book and a calendar for a very long time, and the careful ones ran it well. What a tool moves is where the effort falls. The noticing, the holding, the retrieving, and the first draft of words you write every month anyway. The coding, the thresholds and the judgment about what a transaction actually was stay with you.
Ranking earns more in this job than in most, for an unusual reason. Point reads what has arrived ahead of you and weighs each message by how much it matters and how soon it’s needed. The minute it landed counts for little. In a pile that’s mostly receipts and digests, that weighing is doing something closer to rescue than to sorting. The feed alert and the sentence about somebody going up to four days a week are the two most consequential messages of the month, and on arrival they’re the least conspicuous. How triage decides what needs you is the proper treatment of the weighing itself.
Every thread carries a plain summary in a line. That matters here mostly because of the forwards. A chain of fourteen messages arrives with nothing written above it, and the summary is the note the sender never wrote.
Four capabilities fit this job in particular.
A standing request in plain words covers the interruption layer. Ask to be told when anything arrives saying a bank connection has dropped, or when a named client’s payroll changes come in. You hear once, on the day, and you stop watching for it. That category’s whole problem is that it looks like everything around it and only turns expensive later, so hearing on the day is close to the entire fix.
An ask sitting inside somebody else’s message becomes a dated item without being retyped, with the thread still attached underneath. That’s the payroll sentence exactly, arriving three paragraphs into a reply about a supplier statement. It’s the shape of instruction this job loses most often.
Requests you send are held as things you’re owed, and each one comes back to you on the date you picked. Where an answer has already arrived, the follow-up shows itself as probably settled and waits for you to agree. That’s what makes a monthly query batch safe to chase. Nobody who answered on the twelfth gets asked again on the nineteenth.
And search works on meaning, so what did they tell us about the payments to the yard is a question you can put to the mailbox. That’s the safety net under the section on rules above. It’s what you fall back on for every answer that should have been written down and wasn’t. Attachments also come out of their threads into one list, each still tied to the message it rode in on. Ask a document a question and the answer comes back with a pointer to the part of the file it came off. That’s what a pile of scans named by somebody’s phone actually needs.
Replies come back drafted the way you write, and in a job built on messages that recur, that compounds. The pre-payroll message, the query covering note and the monthly status note are each an edit rather than a composition, twelve times a year. On the months where a query list turns into twenty minutes on the phone, Point runs the scheduling back and forth itself.
Every type of task gets its own position on how far Point should take it unaccompanied, and none of them starts higher than review, which prepares the work and leaves it standing. The dial explains that setting properly. This job has an unusually clean answer about where to put it. Acknowledging a forwarded document, received and coded, is the first thing worth raising. It’s frequent, short, hard to get wrong, and it’s the message that stops clients asking whether anything arrived. Nothing on the payment path belongs anywhere near the top of the dial, for any client, ever. Point does hold back mail it judges risky, and mail from senders it doesn’t recognize, so you decide about those rather than react to them. That’s worth having. It’s still not a control on a payment instruction, and it’s no substitute for the call to a number you already had.
Connecting is a sign-in to the Gmail or Microsoft account the practice already runs, so the address your clients and their suppliers have used for years is the one that keeps working. If you also operate a second business, each one is sealed off from the other. That line is drawn around businesses you run rather than around the clients inside one, which is the right way round here, since much of the value is in seeing that the same client has written from three addresses this week.
What Point doesn’t have is the ledger and everything on the other side of it. Point has never seen a feed. Point holds no coding rules and doesn’t know your threshold. Point can’t post a journal or run a payroll, and has no idea what a transaction was for. If nothing wrote to say a feed has stopped, Point can’t tell you it stopped. That’s the honest limit on the alerting above, and the reason the monthly check on last transaction dates stays a manual habit. Everything Point does is listed on the benefits page, and the same capabilities are arranged around a practice in Point for accountants. Whether a tool should be reading mail carrying client bank details is a prior question rather than a footnote to this one, and it gets a full hearing in is it safe to use AI with client financial data.
Common questions
Should bookkeeping queries go in the ledger or in email?
Both, split by person rather than by firm policy. Most accounting packages hold a query against a transaction and let it be answered in place, which is genuinely better. No transcription, and the answer sits next to the thing it explains forever. That works for a client’s controller or office manager, who’s already in the software several times a week. An owner who has logged in twice since you started answers by mail instead, and a monthly portal invitation won’t change that. So put queries in the ledger for the people who live there, and send them by mail to the people who don’t. Most small clients are the second kind. Everything else in this piece arrives as mail whatever you run: the payroll instruction, the authorization, the alert that a feed stopped, the handover to the accountant.
How often should we actually write to a bookkeeping client?
Three planned messages a month covers most engagements, and they beat any number of unplanned ones. A short request for payroll changes before the cutoff, asking for a nil return so that silence stays silence. The query batch, on the same date every month, so a habit can form around it. And a brief status note saying what’s done, what’s outstanding and what you’re waiting on. That one removes the client’s own repeating questions before they’re asked. Anything urgent goes when it goes. Fixing the other three works because a client who knows when they’ll hear from you answers faster, and you collect that gain twelve times a year.
A client forwards everything with no message. What do we do?
Publish a default rather than asking them to change. Tell them once, in writing, that a forward with nothing written above it gets coded and filed, and that anything needing payment or an answer has to say so in one line at the top. That puts the work of resolving the ambiguity on the only person who already knows the answer. It costs them a few seconds, where guessing costs you ten minutes and occasionally a late payment. Then give the traffic that came from a machine a single address of its own, meaning suppliers, capture apps and billing systems. Those senders are configured once and comply permanently, where a client mid-conversation replies to whoever wrote last. So the address rule works on the majority of this pile, though never on all of it.
We are the accountant. How should we be dealing with the client’s bookkeeper?
Treat them as the fastest responder in the chain and the one with the least authority, and route questions to match. Anything answerable from the records goes to them, and it should come back quickly. Anything answerable only from the client’s memory or their drawer goes to the client directly, because a bookkeeper relaying it adds a week and a paraphrase. Agree once a year who asks the client for what, so the two firms stay out of each other’s week and both requests get answered. Ask specifically for the list of queries that went unanswered and the items carrying a default rather than a real answer, since that’s the only warning you’ll get about which figures are soft. And confirm that your adjusting journals were actually posted. An unposted journal stays invisible for a year and then arrives as wrong opening balances.
Is it safe to connect an AI tool to a mailbox with client bank details in it?
It’s the right question to ask first, and it deserves more than a reassurance. A bookkeeping mailbox is an unusually concentrated thing: bank statements, payment instructions, payroll data and staff details for every client you have, all in one place. The answer turns on what the data actually is, where it travels, what the tool may do with it next, and what your clients have been told. Is it safe to use AI with client financial data sorts that out at length, and the questions to put to any vendor is the list worth sending before a single mailbox is connected.
The short version
A bookkeeping inbox differs from a tax practice’s in three ways that matter. The job repeats twelve times a year with every client live at once, so nothing ever closes and an unanswered item compounds forward instead of holding something up. No single item in it is worth the message that would settle it, so the batch is the only unit that pays. That makes the fixed monthly slot, the stated default for unanswered lines and the written threshold worth more than any improvement to wording. And most of the volume was written by a machine. Nearly all of it is a record rather than a message, and it hides the handful of alerts that say something has stopped and will otherwise cost you two weeks at the next month end.
Around those:
- give unmarked forwards a published default, so the ambiguity is resolved by the person who already knows the answer
- keep authorizations attached to the run, with the amount in them
- send nothing about changed bank details without a call to a number you already had
- put one fixed message before every payroll cutoff, asking for a nil return
Ask while the month is still recent, because bookkeeping answers decay in a way document requests don’t. Write every answer down as a rule rather than a reply, because the same question is otherwise asked again in four weeks. Then treat the accountant at the other end as the holder of the other half of the record. Agree who asks the client what, hand over the unanswered queries rather than hiding them, and confirm the journals were posted. The rest of the practice’s recurring work is handled job by job across the rest of this collection, and the buying question itself belongs to AI email for accountants.