How to track client commitments between check-ins

Ask a CPA or fractional CFO where the commitments from a client check-in live and you get one of three answers. A page of prose in Notion or a shared doc. A task in whatever task system the firm uses. Or the summary a meeting transcription tool generated and emailed afterward.

All three capture what was decided. As the practitioners we spoke with were using them, none produced a complete commitment record, because a commitment record has to answer a question those artefacts do not ordinarily hold: did it happen?

The short answer

A usable commitment record holds four facts: what was decided, what observable result should follow, when it was promised or due, and whether it happened. The fourth is the one the usual artefacts described above are missing, and it is the only one that cannot be filled in from the record itself. It requires a look at the books or the bank.

It also needs one operational date: when to check next. The promised date preserves the commitment as made and is where the first check happens. If the outcome has not occurred by then, how the customer, vendor or company actually behaves sets the next check date. Keep both dates, because they answer different questions.

The follow-through has three parts. Check when the promised date passes. If the outcome has not occurred, mark it past due, use observed behaviour to set the next check, and separate “late but within this counterparty’s usual pattern” from a real deviation. Run a standing sweep of open items and let the exceptions open the next check-in.

This guide draws on qualitative design-partner conversations with CPA and fractional CFO practices. The method is what those conversations pointed to, not a measured comparison of note-taking systems.

Why the usual artefacts are not records

Each of the three usual homes for a decision fails at a different point, and it is worth being precise about which.

Prose notes hold the decision and often the reasoning. They have no due date and no outcome. “Agreed to chase the Henderson receivable and hold the contractor hire until it lands” is a good note. Three weeks later it is still a good note, and it still says nothing about whether the receivable landed or the hire happened. The note does not change when the world does.

Task lists hold a due date, which is an improvement. But a task closes when someone acts, not when the thing happens. “Chase the receivable” gets ticked the day the reminder email goes out. Whether the money arrived is a separate fact, and the task system has no field for it. The task is done and the decision is unresolved.

Transcript summaries are the most complete capture of what was said and the least likely to be read. They are generated automatically, filed automatically, and reopened, in the practitioners’ experience, rarely. Most modern recorders extract action items, which puts them in roughly the position of a task list, with the same gap. The item says “client to send the signed lease.” Nothing checks whether the deposit cleared.

The pattern across all three is the same. They are records of intent. A commitment record has to be a record of outcome, and the outcome lives somewhere else.

The four facts and the check date

What was decided. One line, in plain terms. Not the discussion, the conclusion. “Hold the contractor hire until the Henderson receivable clears.”

What should happen as a result. The observable thing in the world that follows if the decision is carried out. This is usually a transaction: a payment received, a payment made, a payroll line appearing or not appearing, a balance moving. Writing it this way is what makes the decision checkable later. “Hold the hire” is a decision. “No new contractor invoices before the receivable lands” is something you can look for.

By when. The date it was promised or is contractually due. Write the date as made. If the customer is on net thirty, the commitment date is day thirty, whatever you expect to happen. This is the field that later tells you whether the promise held.

Whether it did. Three values, not two. Happened. Did not happen. Cannot tell yet. The third value matters because a payment that is late is not the same as a payment that is not coming, and the record should not force you to pretend it is one or the other before the evidence exists.

When to check next. Separate from the promised date, and the subject of the next section. The first check is on the promised date. This field holds the next one, if the first comes back empty.

Only the fourth fact requires leaving the record. The first three can be written in the ten minutes after the call. The next check date comes from an existing counterparty profile or, where there is none yet, from a look at the payment history. The fourth fact is filled in later, from the books or the bank, and that is where the work is.

The next check date should reflect observed behaviour

The first check is on the promised date, and it is not optional. A customer on net thirty is late on day thirty-one, and the only way to know whether the payment arrived is to look. Looking is cheap: it is the bank feed or the aging report. It does not have to trigger anything.

What practitioners described is what happens after that look comes back empty. The customer on net thirty who has paid on day forty-five for the last eight invoices will, in all likelihood, pay on day forty-five. So the record on day thirty becomes “past due, expected around day forty-five,” the next check goes on day forty-five, and whether the day-thirty miss warrants a chase is a separate call. Chasing a customer who reliably pays on day forty-five changes nothing except the client’s impression that the advisor does not understand their customers. Chasing one who has never paid late before is a different situation, and the record should let you tell the two apart.

This is why continuity, done properly, includes a short profile of each significant counterparty. Not a CRM entry. Two or three lines built from what the books already show: the usual gap between due and paid, whether they partial-pay, whether a chase moves them or not. A firm that has been doing the books for a client already has this information sitting in the payment history. It has usually never been written down, and it lives in the head of whoever has been on the account longest, which is one of the reasons handover is hard. We will cover that in a separate guide.

The same logic applies to vendors and to internal commitments. A supplier who is paid on the twentieth regardless of terms has a check date of the twenty-first. A hire the founder says will start “next month” has a check date of the first payroll after that, not the first of the month.

A task list has one date and treats it as both the promise and the check. It has no way to say “late, and expected on day forty-five.” Holding the promised date and the check date separately is what lets the record stay honest about the commitment while being realistic about the cash.

The sweep

Decisions made in a scheduled check-in are usually captured somewhere. Decisions made between check-ins are less reliably captured, which is its own failure mode. But even the captured ones mostly lack follow-through, and that is a failure of cadence, not of tooling. Practitioners were candid that writing the item down is the part everyone does.

The method is a standing sweep. On a fixed day each week, go through every decision whose check date has passed and fill in the fourth field from the books or the bank. Happened, did not, cannot tell yet. Then do one of three things with it. Close it. Set the next check date, if it is past due and the counterparty profile says the money is still likely to come. Or flag it for the next call, if “did not happen” means the client needs to know or needs to decide something.

The output of the sweep is the opening of the next call. This is the link back to the preparation guide: step two of preparation is reconstructing decisions from the last two calls, and step four is verifying them against books and bank. A firm running the sweep has already done both by the time preparation starts. What is left is reading the current numbers in that context.

Weekly is a default, not a rule. Some engagements run on a biweekly or monthly check-in and the sweep can match that rhythm. What does not work is running the sweep only when a call is coming, because that is preparation under another name and it collapses under the same pressure. The whole point of the sweep is that it is standing.

Using what the accounting system already gives you

Before building anything, use what is already there, because part of this is covered.

Depending on the platform and how it is configured, firms may already have automated invoice reminders that go to the customer on a schedule around the due date, aged receivables reports, and scheduled report emails. An accountant added to the client’s file typically receives the same notifications and can set the reports up to arrive on a fixed day. Where available, that handles a real portion of the sweep for invoiced items: the reminder goes out without anyone remembering to send it, and the aging report lands in the inbox on sweep day.

Two things it does not cover. It does not tell you whether a specific commitment from a call was carried out. It tells you an invoice is outstanding, which is a related fact but not the same one. And it has nothing to say about decisions that are not invoices at all, which in practitioners’ descriptions is most of them: the hire, the distribution, the delayed supplier payment, the price change. There is no object in the books for those until after they happen, so the check has to be a person looking.

For that remaining portion, a sheet is fine. Four columns for the four facts, a fifth for the check date, a sixth for the counterparty. The value is not in the sheet. It is in the sweep.

Who runs it

This does not need to be the partner. The sweep is operational work: open the record, open the books, compare, mark. It is well suited to an associate, an operations lead, or an outsourced bookkeeping resource, with the partner seeing only the items marked “did not happen” or “flag for call.”

The partner’s judgement belongs in two places. Writing the second field, because deciding what observable outcome a decision implies is where the advisory thinking is. And reading the flagged items, because “did not happen” on a distribution the founder said they would hold is a conversation, not a task.

What this costs

At a small client count, a weekly sweep is manageable alongside everything else. At thirty clients it is a real allocation of someone’s time, and the number of open commitments and counterparty profiles grows with it. We are not going to pretend otherwise. What it replaces is the reconstruction and verification work in preparation, which practitioners in our conversations identified as the time-intensive part, and the cost of finding out on the call that a decision quietly did not happen.

Our product

AgentLink (agentlink.finance) is built around this record. Commitments captured with the four facts, promised dates held as made, check dates set from each counterparty’s observed behaviour, and the sweep run daily against the bank and the books so the fourth field fills itself in. The output is the opening brief for the next call. It is sold through CPA and fractional CFO firms. The firm keeps the client, the pricing and the judgement.

Frequently asked questions

Is a task system with due dates good enough?

It is better than prose and was a common starting point among the practices we spoke with. The gap is that a task closes on action, not on outcome, and it has one date where the record needs two. If you use a task system, add a field for the outcome and a second date for the check, and it becomes a commitment record.

How many decisions come out of a typical call?

Practitioners described a handful, usually between two and five. Most are small. The record exists for the small ones, because those are the ones nobody remembers to check.

What about decisions with no clear observable outcome?

Write the closest thing there is. “Think about whether to raise prices” has no outcome, and that is a sign it was a discussion rather than a decision. If it belongs in the record, it needs a next observable step, even if that step is “decision on pricing by the next call.”

Does the client see this record?

That is a firm choice. Some practitioners we spoke to wanted clients to see the forecast and the outstanding items so routine questions could be answered without waiting for the next check-in; others keep the record internal. The next guide in this series covers what the client cannot see from the bank alone.

About the author

Nilanjan Raychaudhuri is the founder of AgentLink (Tublian LLC, Columbus, Ohio), which builds controller-layer software sold through CPA and fractional CFO firms. He has spent the past year interviewing practitioners at fractional CPA and CFO practices about how advisory work is actually delivered. Team page

The practitioner observations in this guide come from design-partner conversations and are used with permission where attributed. Corrections to nilanjan@agentlink.finance.