A bookkeeping mailbox is not a smaller version of a tax practice’s. The same job runs twelve times a year for every client at once, almost nothing arriving in it is individually worth a message, and a large share of it was never written by a person at all. Those three facts decide most of how the pile should be worked.
- Nothing here finishes. A return is completed and gone. A set of books rolls into the next month carrying whatever was not settled, and an item left open does not stay one item.
- The economics run the opposite way from tax work. A single query costs more to send than its answer is worth, and only the batch pays, which turns when you ask into 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 are saying 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 theirs is the only date 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 and the difference is not volume. It is concurrency.
A preparer with two hundred clients has one substantial job per client per year, arriving in waves, and 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 producing transactions, questions, documents and system noise continuously. Twenty-five is a comfortable number of clients and an uncomfortable number of simultaneously open jobs, which is why a bookkeeping mailbox feels heavier than its client count suggests it should.
The second difference is that the work does not conclude. A return is filed and the file shuts. A month-end is signed off and the next one has already been accumulating for four weeks. There is no state in which the list is empty and no week in which you are between jobs, so anything unresolved has somewhere to go: forward.
That is worth being precise about, because it is 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, they are no longer answerable, and the person who finds them is either you in a panic in November or somebody else entirely at the year end. What was 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 only one that runs in your favour, and it is large enough to organise a practice around.
Because the cycle repeats, every improvement you make to it is made twelve times. A tax practice redesigning the way it asks for documents gets one use of that work per client per year. A bookkeeper who fixes the shape of the monthly query message, or the moment in the month it goes out, collects the benefit in February and again in March and again for as long as the client is a client. The same arithmetic runs the other way. A clumsy arrangement is not a mistake you made once. It is a standing charge.
This is also the one setting in a practice where reading the mailbox against a list is genuinely cheap. Running the firm inbox makes the general case that a practice always knows what it is waiting for before the client sends anything. In bookkeeping the list is not assembled per engagement from an organiser. It is the same list every month: the statements, the feeds, the card receipts, the payroll changes, the queries outstanding. It can be written once and reused, which almost nothing else in accounting can, and a firm that has never written it down is rebuilding it from memory a hundred and eighty times a year.
The compression that a tax practice meets for ten weeks, a bookkeeping practice meets as a ridge in the first fortnight 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 is the economics of a bookkeeping query, written out, because 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 compose a message, the client reads it on a phone, thinks, replies with half an answer, you read the reply, go back to the transaction, and code it. That is perhaps ten minutes of two people’s attention spent on a line that will not 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.
How to build the batch itself is not this page’s business, because it has already been done properly. Cutting the list inside your own office before it leaves, splitting the lines a client can answer from memory from the ones that send them to a drawer, proposing an answer wherever being wrong changes nothing, and saying at the top which few lines actually matter: all of that is in year-end close, and none of it changes at monthly frequency. What changes at monthly frequency is everything around the list.
Three things, and the first is the one firms are most surprised by.
Give the batch a fixed slot and never move it. Queries on the twelfth of every month, whatever else has happened. This is available to bookkeeping and to essentially no other job in a practice, because the job repeats often enough for a client to form a habit around it. A client who receives your questions on the twelfth learns, without ever being told, that the twelfth is when they deal with you, and after four or five months they start answering the same day. A client who receives questions whenever their file happens to reach the top of your pile learns nothing at all, because there is nothing to learn. The gain here is not politeness. It is that 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, and make it a written position rather than a monthly judgement. There are only 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 experiences 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, which means the threshold drifts with mood and workload and cannot be explained to a client who asks why one small payment got a question and another did not. A stated threshold, agreed with the client, is the single fastest way to shorten a monthly query list, and it is the only one that gets easier every month rather than harder.
What a client can still remember
There is a reason bookkeeping queries go stale in a way tax queries do not, and it is not about diligence.
Most tax questions point at a document. A statement, a form, a certificate, a completion letter. Documents keep. Ask in July for something that was issued in February and it is still exactly as obtainable as it 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. There is often no document anywhere, because the event was somebody buying something small on a Tuesday. The only record is in a person’s head, and it decays fast. Within a fortnight the answer is easy and accurate. At three months it is a guess. At six it is a guess offered confidently, which is worse, because it arrives looking exactly like a fact and goes into the ledger as one.
So lateness in this job is not only a scheduling cost. It is a quality cost, and it is invisible, because a bad answer and a good answer are the same length.
That sets the real deadline on the query batch. Not before the close, and not before the year end. While the month is still recent. For clients whose records you can see as they happen, the cheapest query you will ever raise is the one raised in the week the transaction landed, when the client can answer it from the last thing they did rather than from an archaeology of their own card statement. Raising a few during the month and sending the rest on the twelfth is not inconsistent with batching. It is the recognition that 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 will not be answered on the fourth, and the fourth ask spends goodwill you are going to need for something that actually matters. Past a point, the honest move is to apply your stated default, tell the client in one sentence what you did and why, and invite a correction. That is not giving up. It converts an open item that will never close into a closed item that is probably right and is certainly visible, and it 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 is a fact about one transaction, or it is 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. Look at a client you have had for eight months and count the queries in month one against the queries in month eight. On a stable business those numbers should be falling steeply. If they are flat, then nothing you have been told is being kept, and you are paying your client the same ten minutes over and over for information they 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, and the person coding it, who may not be the person who asked, has no way to know the question was already settled. The answer existed. It was just filed in the mailbox, which is a record of what arrived and not a record of what is true.
So the rule is short. The mailbox is where an answer arrives. It is never where an answer lives.
Where it lives depends on your ledger. Most accounting packages will hold a coding rule against a payee, and that is the right home for anything that will recur, because it acts on the next transaction without anybody remembering. What no ledger holds is the rest of it, and the rest is most of the value: 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 do not, the transfer that looks alarming every quarter and is not. Those are facts about a client, they are stable 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 will go on being wrong silently in a way a query never does. A business that changes what it does will start generating transactions that the old rule swallows without comment. It is worth reading the list of standing rules for a client once a year, at the point where you are already thinking about that client, which is the close.
The same recurrence runs on the inbound side. Clients ask the same questions monthly too, and mostly they are 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 is specific here is that a monthly cycle makes the repetition predictable, which means it can be answered before it is asked. A short fixed message at the same point each month, saying what is done, what is outstanding and what you are waiting on, removes a category of inbound mail that no amount of good replying will ever remove.
The mail that nobody wrote
Open a bookkeeper’s inbox next to a tax preparer’s and the visible difference is not the clients. It 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 the first thing to say about it is that nearly all of it is a record rather than a message. A statement ready notice is not asking for anything. It exists so that a search in nine months can prove the statement was available. Filing it is correct. Reading it is not, and neither is deleting it.
The second thing to say is that hidden inside that layer is the most time critical mail you get.
A bank feed that stopped. An authorisation that expired and needs the client to sign in again. A card that funds a payroll subscription and has been declined. A filing that was rejected rather than accepted. A scheduled payment that did not 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.
There is a test that separates them cleanly, and it is worth stating because it is not obvious from the wording. The messages that matter are announcing that something has stopped. Everything else is confirming that something happened. A message about an event is a record. A message about an interruption is work.
What makes the interruption class expensive is that it fails silently by construction. A feed that dropped on the sixth produces no gap you can see, because a missing transaction leaves no mark. You find it on the third of the following month, when the file will not reconcile, and now you are doing a manual import, re-checking a period you had 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, separate from everything else machine generated. There are usually fewer than a dozen of them across a whole client list, and they are known 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 is not read.
Decide, per client, which of their operational notices should be addressed to you rather than to them. This is the part most practices never do, and it is why the expiring card notice goes to an owner who ignores it. Adding your address to the alerts that concern the books, at the point where you are already setting the client up, converts a fortnight of silent breakage into a message on the day.
And check the thing itself rather than trusting the alert. This is the caveat, and it is the reason the first two are not a control on their own: some breakages send no mail at all. A feed can simply go quiet. The only reliable check is looking at the date of the last transaction on every feed, once a month, which takes a few minutes across a whole client list and catches exactly the failures the mailbox cannot show you.
The forward with nothing written above it
A large part of a bookkeeping inbox was never addressed to you in any meaningful sense. It was pushed at you.
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 was given 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.
The problem with an unmarked forward is that it is ambiguous between at least four different asks, and the sender knows which one and you do not. Pay this. Code this. File this. Answer this. They all look identical, and the cost of guessing wrong is asymmetric: filing something that needed paying is a late payment, and paying something that needed filing is worse.
There is a second loss. The forward strips the context that made it meaningful. Whatever the office manager knew when they pressed the button is in the chain above, or in their head, and 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 do not.
Say once, in writing, what an unmarked forward will be treated as. Coded and filed. Not paid, not answered, not treated as an instruction. 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, because it is one sentence and it is obviously reasonable, and it holds up far better than asking them to categorise things.
A dedicated address for this class of traffic is worth more here than it is elsewhere 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. That objection does not apply to most of this pile. Suppliers, capture apps, billing systems and a client’s own accounts software are not in a conversation with you. They send wherever they are configured to send, they are configured once, and they comply forever. The address rule works perfectly on the mail that is not from a person, which here is the majority of it.
Then there is the duplicate. The same invoice reaches you three times: once from the supplier, once forwarded by the client, once through the capture app. This one is worth being blunt about, because bookkeepers reliably try to solve it in the wrong place. You cannot deduplicate a mailbox reliably, and you should not try. The defence against posting or paying something twice sits at the point of entry into the ledger, where the document number and the amount can be checked against what is already there. The mailbox is where things arrive. The ledger is the register of what has been dealt with. Treating the first as the second is the root of most of the anxiety in this part of the job, and no amount of foldering fixes it.
When those invoices are your own rather than a client’s, the pile behaves differently and has a page of its own in supplier and software invoices in the firm’s own inbox, including what to do about the ones that are not real.
The messages that move money
Bookkeepers sit on the payment path, which changes what parts of the mailbox are allowed to be casual.
Two kinds of message live here and only one of them is safe in email at all.
The first is authorisation. Somebody approves a payment run, and they do it by replying, which makes that reply the entire audit trail for money leaving a business you do not own. Two things follow. The approval has to travel with the run rather than staying in a thread, because in eleven months the question will be who authorised this and the answer needs to be a document rather than a search. And the approval has to contain the quantity. A reply saying “yes, go ahead” above a quoted message is not an approval anybody can rely on later, since it does not establish what was actually being agreed to. The version that survives names the total, the count and the payment date, and 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 is travelling. 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. That is not a comment on any particular client’s security. It is that the message is the thing under suspicion, so nothing inside it can be used to check it.
It is worth understanding why the bookkeeper is the target rather than the owner, because 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 is not yours. And you are outside the business, so you have no feel for whether a request is out of character, and a change in routine does not look strange to you the way it would to somebody who sits ten feet from the person supposedly asking.
The arrangement that holds is written down at the start: who can authorise what, up to what amount, through which channel, per client. The value of having written it is not that it prevents anything by itself. It is that it gives you something to point at on the afternoon you decline to do something, which is 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 are 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 not that. People get paid on a day, the day does not move, and missing it is the one failure in this job that everybody notices immediately.
Its shape in the mailbox is specific. There is a fixed cutoff, and there is 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 are told 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, which 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” appears in the middle of a reply about something else entirely, has no attachment, and does not mention payroll anywhere. It is the highest consequence sentence in your month and it is structurally invisible: not a document, not a request, not in a thread about pay.
And the silence, which is genuinely ambiguous. No reply from a client before a payroll cutoff means either that nothing changed or that nobody looked, and those are the same message.
What handles all three is one fixed message before every cutoff, and its distinguishing feature 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. An absence of reply is not, for the same reason that silence on a set of draft accounts is not 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 is 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 removes 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 or VAT filing, a pension submission, a periodic return the books feed. None of those dates belong in a mailbox at all, because they are known a year in advance and belong 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 is 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 judgements and a filing date that a tax authority set. Neither of you has a contract with the other. The client has one with each of you, which is a small fact with 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. If you pass each one on and pass the answer back, every question grows a week and arrives at its destination third hand, paraphrased by somebody who was not sure which part mattered. The rule that sorts this is worth agreeing 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. What kills this arrangement is nobody having stated it, after which both of you assume the other is asking, and 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, and if they are not posted then next year’s opening balances are wrong and nobody finds out for a year. This is the quietest failure in the whole relationship and its cause is entirely presentational: the message looks like the end of a conversation when it is actually the start of a task. What fixes it is a confirmation going the other way. Posted on this date, and the trial balance now agrees to yours. That message is worth far more than its length, because it is the only moment in the year when two separate systems are known to agree, and if it is never sent then 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. This is a scheduling problem rather than a wording problem. It is solved 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, and the part specific to this direction is what is always missing from it. Firms send the file, the trial balance and the date the books were closed. What they leave out is the list of queries that were never answered and the items that carry a stated default rather than an answer, because it feels like an admission. It is the opposite. It is the most useful page in the pack, it is the only warning the accountant will get about which figures are soft, and withholding it does not make the softness go away. It relocates it into somebody else’s return.
If you are 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, so 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 the assumption that they were is the reason opening balances go wrong.
Point in a month that repeats
None of the above is software. Bookkeepers ran all of it on a day book and a diary 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 judgement about what a transaction actually was do not move at all.
Ranking earns more in this job than in most, and for an unusual reason. Point goes through what has arrived ahead of you and weighs every message on how much it matters and how soon, rather than on the minute it landed. In a pile that is 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 both of them are, on arrival, 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, which matters here mostly because of the forwards: a chain of fourteen messages arriving with nothing written above it is exactly the case where 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, and you hear once, on the day, rather than watching for it. Against a category whose whole problem is that it looks like everything around it and only becomes expensive later, that is close to the entire fix.
An ask sitting inside somebody else’s message becomes a dated item without being retyped, with the conversation still attached underneath. That is precisely the payroll sentence, arriving three paragraphs into a reply about a supplier statement, and it is the shape of instruction this job loses most often.
Requests you send are held as things you are owed rather than disappearing into a sent folder, and they come back on the date you chose. Where an answer has already arrived, the follow-up marks itself as probably settled and waits for your agreement, which is what makes a monthly query batch safe to chase at all: nobody who answered on the twelfth gets asked again on the nineteenth.
And search reads for meaning rather than exact words, so what did they tell us about the payments to the yard is a question you can put to the mailbox. That is the safety net under the section on rules above, since it is what you fall back on for every answer that should have been written down and was not. Attachments also come out of their threads into one list, each still tied to the message it rode in on, and asking a document a question gets you an answer with a pointer to the part of the file it came off, which is 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: frequent, short, hard to get wrong, and 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 does not recognise, so you decide about those rather than react to them. That is worth having, and it is not a control on a payment instruction, nor a 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 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 does not have is the ledger and everything on the other side of it. It has never seen a feed, it holds no coding rules, it does not know your threshold, it cannot post a journal or run a payroll, and it has no idea what a transaction was for. It cannot tell you a feed has stopped if nothing wrote to say so, which is 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, the same capabilities are arranged around a practice in Point for accountants, and 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 will 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 is already in the software several times a week. It does not work for an owner who has logged in twice since you started, and sending them a portal invitation monthly will not change that. So put queries in the ledger for the people who live there and send them by mail to the people who do not, and accept that most small clients are the second kind. What no ledger holds is everything else in this piece: the payroll instruction, the authorisation, the alert that a feed stopped, the handover to the accountant. Those arrive as mail whatever else you run.
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, which asks for a nil return so that silence is not an answer. The query batch, on the same date every month so a habit can form around it. And a brief status note saying what is done, what is outstanding and what you are waiting on, which is what removes the client’s own repeating questions before they are asked. Anything urgent goes when it goes. The point of fixing the other three is that a client who knows when they hear from you answers faster than one who does not, and that gain is collected 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 will be 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, and it costs them a few seconds where guessing costs you ten minutes and occasionally a late payment. Then give the traffic that is not from a person, meaning suppliers, capture apps and billing systems, a single address of its own. Those senders are configured once and comply permanently, unlike a client mid-conversation, so the address rule works on the majority of this pile even though it never works 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 accordingly. Anything answerable from the records goes to them and 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 that the two firms are not sending overlapping requests in the same week and getting neither answered. Ask specifically for the list of queries that went unanswered and the items carrying a default rather than a real answer, since that is the only warning you will get about which figures are soft. And confirm that your adjusting journals were actually posted, because an unposted journal is 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 is the right question to ask first, and it deserves more than a reassurance, because 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. What it turns on is 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, which 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 a record rather than a message, hiding the handful of alerts that say something has stopped and will otherwise cost you a fortnight 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 authorisations attached to the run with the amount in them, send nothing about changed bank details without a call to a number you already had, and put one fixed message before every payroll cutoff that asks for a nil return. Ask while the month is still recent, because bookkeeping answers decay in a way document requests do not, and 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.