The work is done and the row is still open. Your client answered on Tuesday, by phone, about something else. The invoice went out that afternoon. Your list still holds Tuesday morning’s picture. On Thursday it tells you to chase her for it, with complete confidence.
The chapter before this one ended on that Thursday. This one is about the step that would have spared you it, which is closing the row. Every other treatment of this reaches for discipline, and discipline is the part that keeps slipping. The question underneath is the one worth your time. How does anything know a thing is finished?
- A list can be wrong two ways, and one costs far more than the other. The cheap-looking one is the one that ends the arrangement.
- Closing is the one act in the sequence that pays you later instead of now.
- Whether something is finished is usually a fact at the far end, and the evidence for it usually sits somewhere you can already see.
- A system that asks beats one that decides on its own, and it stays that way while the asking stays cheap.
Two ways a list can be wrong
The failure everybody plans for is the missing row. Something was asked, it slipped past capture, and you find out in October when the client mentions it. That error is expensive out in the world. It’s gentle on the list itself, because the list kept its honesty. You simply didn’t know.
The other error is Thursday’s. The row is there, dated and detailed, and it describes work that finished two days ago. Out in the world it costs you thirty seconds of checking. Inside, it costs you a small note: the thing you’ve started to rely on just sent you after a client for something you already had.
That note is the whole cost, and it grows. It draws on the same account the last chapter named. You granted your attention in advance, and it stays granted while the claims on it keep earning their place. Four or five stale rows and you start opening prompts to decide whether they’re true rather than to act on them. That’s a different activity. It takes four times as long, and in a bad week it gets skipped.
Three things make the stale row a worse problem than it looks.
It hides in plain sight. A row that’s genuinely open and a row that finished last month look identical. The face of it carries no mark and no fading. So you audit one item at a time, and auditing an item costs about what doing it would have cost. A list you have to verify before you trust it has stopped doing the job you keep it for.
The population only grows. Every task you’ve ever finished stays a candidate for this failure until somebody performs the closing act. Missed asks are bounded by how many people write to you. Stale rows are bounded by how much you’ve ever done.
Better capture makes it worse. This is the part that matters for a series like this one. Each of the four chapters before this installed something that creates rows. One gives you an ask lifted out of a paragraph. One gives you a wait recorded when a thread goes quiet. One gives you a handoff written down while the conversation is still warm. One gives you a date to chase on. Retiring a row is the piece still missing. A system that captures well and closes badly degrades, and it degrades fastest for the people who followed the advice most carefully.
So it’s worth being precise about which way you’d rather be wrong. You’d rather the list forget something occasionally than lie to you routinely. The forgetting costs you a client once. The lying costs you the list.
The step that buys you nothing today
Closing a row gets skipped by everyone, and the reason sits in the act rather than in you. It has four things working against it at once.
You’ve already collected the value. Every other step in the loop pays you the moment you take it. Reading the message tells you what’s needed. Writing the reply discharges the obligation. Sending it ends the discomfort. Closing the row pays somebody else: a version of you next Thursday, who’ll never know what they were spared, because what they were spared is a prompt that stayed quiet.
It happens in the wrong place. You finish by writing a reply, so you’re standing in a thread. The row lives somewhere else. Closing starts with leaving the place where the work happened. That’s the reconciliation tax this series has now named three times, and it peaks right here, because the moment you finish something is the moment you most want to stay put.
It depends on you noticing. The world announces the send and leaves the finishing to you. Pressing send is an event. Being finished is a conclusion you draw about that event, and drawing it takes a second of thought that sits outside anybody’s schedule.
Skipping it feels free. The day goes fine. The consequence arrives three weeks later, attached to a different row. By then it reads as unreliable software rather than as the two seconds you spent elsewhere.
One profession found this drift intolerable, and it answered with a rule rather than with encouragement. Closure got a name and a date.
AU-C section 230 is the AICPA’s audit documentation standard. Paragraph .09 requires that the auditor record “who performed the audit work and the date such work was completed” and “who reviewed the audit work performed and the date and extent of such review.” Then paragraph .16 puts a wall at the end: the auditor should “complete the administrative process of assembling the final audit file on a timely basis, no later than 60 days following the report release date.” That date has its own name. The documentation completion date is the date “on which the auditor has assembled for retention a complete and final set of documentation in an audit file.” After it, paragraph .17 keeps that documentation in place through a retention period that “should not be shorter than five years from the report release date.”
For audits under PCAOB standards the same wall stands much closer. AS 1215 paragraph .15 now requires the final set to be assembled “as of a date not more than 14 days after the report release date.” That change took effect for the largest registered firms for fiscal years beginning on or after December 15, 2024. For all other registered firms it took effect for fiscal years beginning on or after December 15, 2025. Anything added afterward “must indicate the date the information was added, the name of the person who prepared the additional documentation, and the reason for adding it.”
Sixty days and fourteen days are policy choices. Two bodies looked at the same problem and landed apart. Both treat the shape as settled. A closure is a dated act performed by a named person, and the record of it outlives the file it closed.
Your task list sits well outside all of that. These are file assembly rules for audit engagements, plenty of firms reading this stay clear of audit work, and regulators leave your row-ticking alone. The shape is the part that travels, and it lands as one practical requirement. When a row closes, something should record that it closed, when, and on whose say-so. The question that comes up six months later is whether anybody can show the work was done. A closure with something behind it answers that. A bare tick leaves you where an open row would.
Finished is a fact at the other end
Here’s why closure resists the obvious kind of automation.
The first chapter set out the endings a loop can have, and the ordinary one takes two acts. You assert that the conditions have been met. The person who asked declares that they’re satisfied. Yours is the easy half, and theirs is the half that closes it. Whether the thing is finished is, in the general case, a fact held by somebody else.
American tax practice has the cleanest version of this, because there the far end is a computer that answers. The Internal Revenue Service says so in as many words in Publication 1345: “An electronically filed return isn’t considered filed until the IRS acknowledges acceptance of the electronic part of the tax return for processing.” Transmitting isn’t filing. “Accepted returns meet the processing criteria and IRS considers them ‘filed’ as soon as the return is signed electronically or through the receipt by the IRS of a paper signature. Rejected returns don’t meet processing criteria and the IRS considers them not filed.”
So the handbook builds a retrieval step into the job. “The ERO should check acknowledgment records regularly to find returns requiring follow-up action and should take reasonable steps to address issues identified on acknowledgment records.” Where a rejection stands, the originator “must take reasonable steps to inform the taxpayer of the rejection within 24 hours.” (Publication 1345, Rev. 12-2025.)
Read what that arrangement assumes about people. A practitioner who has pressed transmit believes the return is filed and moves on, and the process is what brings them back to look. It takes ordinary practice as given and builds around it. It’s a rule built around the exact moment this chapter is about, which is the gap between doing the observable thing and the thing being done.
Most of what you handle stays quiet at the far end. The surveyor takes the file and moves on. The client takes the schedule and stays silent on whether the board can approve it. The structure holds everywhere, and it hands you the question to ask of any open row. What would have to exist in the world for this to be over, and where would it exist?
Usually something does exist. That’s the useful discovery, and the next section is where it lives.
Where the proof of doing it already sits
Most finished work leaves a trace, and most people walk past it, because a row is the kind of object you read rather than question. Here are six kinds of evidence, from the strongest down, with what each one actually proves.
They said so. “Got it, thanks.” One line, all courtesy, and it’s the strongest signal available, because it’s the other person performing the act that ends the loop. It’s also the message most likely to be archived unread. It looks like a pleasantry and it’s a legal-grade closing. If you change one habit out of this chapter, make it that one. Read the two-word replies.
A record outside the conversation changed state. The acknowledgment file. The portal showing the return accepted. The e-signature service reporting all parties signed. The payment on the bank feed. The shared folder with the file in it. These are the strongest evidence for anything with a deadline behind it, and only a real event produces one. You can check them on your own, which is why the last chapter treated a prompt to go and look as cheaper than a prompt to chase.
Your own reply, carrying the thing. The schedule attached. The figure in the second line. The date named. Strong evidence when the ask was for an object, and weaker than it looks when the ask was for a judgment, because a judgment can be answered badly.
A follow-on message that assumes it. They write back asking about the third page, so the document reached them. Indirect, and often the earliest confirmation available.
You told somebody else. The line you typed to a colleague at 11:40 saying the schedule went out. A good indication rather than proof, and frequently the one trace left when the work happened somewhere your mail can’t see.
Nothing at all. The phone call. The corridor. The client rings about the audit letter and mentions in passing that the invoice is fine at the original figure, so you send it and the whole thing stays in your head. This is Tuesday, in the scene that ended the last chapter, and it’s common. It’s a large fraction of a working week in a firm where people still talk to each other.
That last category sets the ceiling on what any software can do, and it’s worth saying plainly where the ceiling sits. Detection reaches exactly as far as the traces reach. Something reading your mail finds the first five. The sixth stays with you, because it happened somewhere only you were. So the honest design goal is a list that closes the five and puts the sixth in front of you, cheaply enough that answering it takes a second.
One caveat belongs here rather than later. Deciding whether a particular reply satisfied a particular ask means reading ordinary sentences that were written for another purpose entirely. That’s an inference drawn from language rather than a lookup, and it carries an error rate somebody has actually measured. The numbers are in email task management, without writing it down. Having read them is why everything below is about being wrong gracefully.
Messages that look like finishing and are not
Treat “you replied on the thread” as “you finished the task” and you’ll be wrong in a predictable set of cases. The set is worth knowing either way, because you make the same mistake yourself when you skim a thread on a Friday.
The promise. “I will have that over to you Monday.” It sits in the reply slot and engages directly with the ask. It’s the opposite of completion. It’s a fresh commitment on a tighter date, which the first chapter called the obligation that outranks the original. Close on it and you’ve deleted the harder of your two promises and kept neither.
The partial. They asked for three things. You attached two and said you’d follow up on the valuation. The row closes, the third item leaves the system, and it surfaces in a meeting.
The wrong answer. You replied to the question you remembered rather than the one that was asked. That happens most on threads open long enough for the two to drift apart. The conditions of satisfaction were always theirs. Your reply is evidence that you responded.
The deferral. “Let me check with Priya and come back to you.” That’s movement, and it’s a handoff wearing the clothes of an answer.
The other ask in the same message. The most common of the five, and the most damaging, because a single message routinely opens two loops pointing in opposite directions. You answered the schedule question. The invoice question sat in the same paragraph, and it’s now buried under a reply that makes the whole thread look handled. That’s worse than where it started.
The rule underneath all five is one line. A reply is evidence about a thread. A task is a claim about an ask. They come apart exactly where the ask was hard, which is to say where being wrong costs the most.
The existing tools do something here, and it’s fair to say what. The mainstream instruments cover the inbound half. They watch for a reply arriving and cancel the chase when one does. Boomerang’s home page describes its follow-up reminders in one sentence: “You can select to only be reminded if nobody replies, or regardless” (checked September 6, 2026). That’s a real feature and the right idea for a wait. It covers the direction where somebody owes you. Whether you did the thing somebody asked you to do sits outside it, and it reaches as far as the messages you remembered to mark before sending. That’s the limit the last chapter put on the whole category. Point compared with Boomerang goes through the rest of it.
Which way a system should be wrong
Any rule here will be wrong sometimes, and you get to choose which way. One cost dwarfs the other.
Close a row wrongly and the loop leaves the system in silence. A second prompt would need something to prompt about, and from the software’s point of view the matter is settled. The work is back in your memory alone, which is the arrangement this entire series exists to replace, and this time you believe you’re covered. You find out from the client. That’s the highest cost available, with the least warning.
Ask wrongly and it costs one click and about three seconds, plus a small draw on the same attention account as everything else.
So a system should ask. That’s worth saying out loud, because “ask” earns its safety rather than arriving with it. Two conditions hold it up, and both are about the asking rather than about the noticing.
The asking has to be cheap. Cheap means it appears where you already are, rather than in a place you have to go. It means one click settles it either way. And it means turning it down is free: the suggestion you decline leaves the row open, quietly, and tomorrow stays quiet too. A prompt you have to handle is a task about a task, and you now have more of those than you started with.
The reason has to be on the row. “Looks done” by itself asks for faith, and faith is a lot to extend to a piece of software about the state of your obligations. “Looks done, because you sent the March schedule to Hallett at 11:12 on Tuesday” is a claim you can check in one glance, against something you remember. The glance is the whole safety mechanism. It’s also what makes agreeing quick, because you’re confirming a specific fact rather than authorizing a guess.
There’s a third position worth naming, because systems miss it and so do people. Sometimes the work is done and the loop stays open, because the far end has yet to acknowledge. The file went to the surveyor and the surveyor is still reading it. That one is neither a task nor a closure. It’s a wait, and where a wait goes was settled two chapters ago. A system that collapses “you did your part” into “it’s over” reopens the exact gap that Publication 1345 built a retrieval step around.
The click that turns into a reflex
An honest chapter puts the objection to its own proposal in the middle rather than at the end, so here it is. A system that says “looks done” and waits for one click has invented a click. Clicks become reflexive, and a reflexive confirmation launders a guess into a decision. That’s worse than staying quiet.
This has been studied properly, in cockpits rather than inboxes. Kathleen Mosier of San Jose State University and NASA Ames Research Center defined the thing precisely, with Linda Skitka, Susan Heers and Mark Burdick. Their paper is Automation bias: decision making and performance in high-tech cockpits, published in the International Journal of Aviation Psychology in 1997. The term “refers to omission and commission errors resulting from the use of automated cues as a heuristic replacement for vigilant information seeking and processing.” Errors of omission are the ones you miss because the automation stayed silent. Errors of commission are the ones where you follow it and it was wrong.
Two findings from that literature are worth carrying over, and one non-finding.
The non-finding first, because it removes an easy comfort. Linda Skitka, Kathleen Mosier, Mark Burdick and Bonnie Rosenblatt compared two-person crews with people working alone. Their paper is Automation bias and errors: are crews better than individuals?, published in the same journal in 2000. “Teams and solo performers were equally likely to fail to respond to system irregularities or events when automated devices failed to indicate them.” A second pair of eyes came out even. If your practice is two people and your plan is that your partner will catch it, treat that as comfort rather than as a control.
The first finding is that training helped, halfway: “Training that focused on automation bias and associated errors successfully reduced commission, but not omission, errors.” Knowing about the problem made people better at catching a wrong suggestion. The things the system never raised stayed where they were.
The second is the useful one. In the 1997 study, the pilots who checked were the ones who felt answerable. Those “who reported an internalized perception of ‘accountability’ for their performance and strategies of interaction with the automation were significantly more likely to double-check automated functioning against other cues and less likely to commit errors than those who did not share this perception.”
These are glass cockpits and flight scenarios, a long way from four-person firms and email, and the sample sizes are small. Take the direction rather than the magnitude. The direction says that the interface and the second pair of eyes both come second. What keeps a confirmation honest is a felt sense of being the one who answers for the outcome. For the pilots that was an experimental condition. For you it’s the engagement letter, and it’s the same obligation the handoff chapter found sitting behind delegated work.
The practical version is a line, drawn once, between what you agree to from the row and what you go and look at. Three kinds get the look.
Anything with a statutory deadline behind it, where the evidence of completion lives at the far end and you can go and retrieve it. Publication 1345 already tells an e-file provider to go and check the acknowledgment. The same rule holds wherever an acknowledgment exists.
Anything whose finish line is a fact about a third party rather than about you, which is most handed-off work and nearly all of what a client owes you.
Anything where the ask was a judgment rather than an object. There the question is whether your reply was right, and that’s a judgment a system reading your sent mail leaves to you.
Everything else, agree from the row and move on. Drawing the line matters more than where exactly you draw it. A rule that says check everything lasts until the first busy week. A narrow rule you keep beats a wide one you drop.
What Point does when a task looks done
Point is the mail client rather than a tracker sitting next to one, so the place the work happens and the place the row lives are the same surface. That’s what makes the noticing possible at all. There’s one surface holding one opinion, so there’s nothing to reconcile.
An ask that arrives in a message is already a dated task with the conversation attached, which is where this series started. This chapter adds the other end of it. You answer the client the ordinary way. You write the reply, attach the schedule, and send it. The task stays where it is, because touching the task is the step everybody skips. Point notices, and marks the row as looking done, with the reason showing: which message, and when.
At the setting every kind of action starts on, the suggestion sits on the row and waits. Point leaves the closing to you. If the work is still live, one click keeps the row open, and that’s the end of it. If it’s finished, one click agrees. The closing is recorded like everything else Point does, so taking it back starts from the entry that logged it.
Then the list changes character, and this is the part that’s easy to miss. It starts counting what you finished as well as what’s outstanding. A list that only accumulates is a list you eventually stop opening, for the reason the first section of this chapter set out. A list that retires its own rows is one you can still read in March.
The Tuesday phone call stays yours. It left no trace anywhere, so it stays a thing only you know. What changes is the row. It’s in front of you, on the list you were going to read anyway, one click from closed, instead of waiting to become a chase on Thursday.
Sometimes what you’re waiting for is a state change somewhere else. A portal showing the return accepted. A confirmation landing. The file appearing in the shared folder. Say that in plain words and it becomes a watch rather than a task. A watch speaks once, when the thing happens. Setting your first watch in plain words is how one gets written.
Each kind of action carries its own level, and that level decides how far Point goes alone: suggesting only, preparing something and holding it, or handling it outright. Every kind begins at the middle level, so a higher setting is somewhere you moved it. Point’s actions are logged in plain sentences, in sequence, and that log is where reversing one begins. Mail that’s already been delivered is the standing exception, because it’s sitting on another company’s server. The benefits page lists the rest.
One thing stays yours throughout: whether a thing was done well. Point can tell you that a reply went out and what was in it. Whether it answered the question the client was actually asking is a judgment, and that stays where it was.
Everything that now has something to say
Take stock of what five chapters have installed, because the total is the next problem.
Asks are lifted out of paragraphs and dated. Waits are recorded with the day their silence starts to mean something. Handoffs are held with a name and a return leg. Chases arrive early enough to leave room. Watches sit on the conditions still to fire. And now closures suggest themselves as the work finishes, so the list is finally telling the truth about what’s open.
Every one of those is a thing that wants to speak to you. That was the point. A record that stays silent is the problem the fourth chapter opened on, and this is the fix working exactly as designed.
Now come back from four days at a client’s premises. It’s Monday, a little before eight. Two chases are due, and one of them resolved itself while you were gone. Three watches fired on Thursday and Friday. Six tasks look done and are waiting for a click. Marcus needs an answer. The surveyor confirmed. A filing was accepted. And two hundred and forty unread messages sit underneath all of it.
Every one of those is right. Each is a correct claim on your attention, produced by a system doing precisely what you asked. And arriving together, at eight on a Monday, they look exactly like the noise you installed them to escape. That is the last thing this series has to solve.