Would you like to take a fascinating journey through the minds of control-obsessed technical accountants building foundational processes?

Let’s walk through a discussion we had with our Development team. We did our best not to bury them in minutiae, but what began as a straightforward conversation about payment posting took a few turns through the wonderfully particular world of Accounting, Finance and Payment Processing.

In a warehouse, month-end cutoff could come down to a familiar question: Did we sell FOB shipping point? Did the truck leave the yard before or after month end?

The answer depended on the terms of the sale and when the relevant event happened. The invoice date wasn’t necessarily the answer. The warehouse needed to know what happened, when it happened, and have evidence to support it.

We found ourselves asking the same kind of question about payments. Customers pay online through our 24×7 portal and virtual agent. The payment goes immediately to a processor, then waits in a queue for staff to post it to our system of record the next morning. We have been using the post date for month-end cutoff. That seemed straightforward. Until we started thinking through what was actually happening.

The payment was taken one day and posted the next. We had a date for the posting, but not the time. And in the legacy process, we didn’t know whether a payment matched a valid debtor account until someone tried to post it. If it didn’t match, it never posted and was returned.

The manual process gave us a practical boundary: staff posted during defined work periods. A date-only field was workable in that process. It was also imprecise. A payment could be received just before month end but be posted by staff the next day, putting it into the new month under our existing posting cutoff.

Now we’re changing the process, making improvements. Successful payments will post directly to the system of record as they arrive. Manual batch posting finally fades away along with the buggy whip. That is better for the business. It also means posting can happen continuously, including right around month end.

Wait. If posting is continuous, don’t we need the time as well as the date?

Absolutely. We need to distinguish a payment successfully applied at 11:59 p.m. from one applied at 12:01 a.m. We need the actual date and time of that account posting, and we even need agreement on which time zone defines midnight.

These sound like small technical details, until they move activity from one reporting period to another.

Then we considered another question: what exactly does “post” mean?

The new system needs to record every incoming payment so we can control and track it. But sometimes it won’t be able to match a payment to a valid debtor account. We want those payments to enter a hold queue while the error is resolved. That gives us better visibility and stronger controls over resolution and refunds. But an entry in the hold queue is not the same as applying the payment to a debtor account.

The account match is where we identify the applicable contingency rate and can calculate the fee. So the hold-queue date and the debtor-account post date represent different events. If the exception is resolved, the payment gets an account-post date and time then. If it is returned without ever being applied, it never gets one.

That distinction matters for accounting. It gives us a clear operational milestone for calculating and recording the fee.

It also raises another question: if the payment arrived before month end but wasn’t matched until afterward, does the fee belong in the earlier period? We can’t answer that simply by pointing to the posting date. We need to consider the contractual earning terms, the information available at close, and whether we can support an estimate of the related revenue.

Until the account is identified, we can’t determine the exact contingency rate, but “we don’t know the exact amount” and “we can’t reasonably estimate it” are different conclusions.

For these exceptions, our current assessment is that the information available before a valid account match does not support a reasonable fee estimate. That conclusion needs evidence. We need to quantify the queue, review how items are subsequently resolved, and reassess whether those outcomes provide a basis for an estimate or a period-end adjustment.

By now, we may be losing the non-accountants in the room. Regardless, the question remains: does the fee belong in this month’s revenue?

Wait, there’s more. We thought about direct payments to our clients. Those have another set of dates. The debtor pays the client. The effective payment date is the date the client receives the money, not the date our company receives a payment file or notice.

We may not learn about a payment until a week or two later. Today, we post it when we receive and process the client’s report. We aren’t changing that operational process in this project. But we do want to capture when the client notified us, so we can measure the reporting lag and investigate differences between our debtor balances and the client’s records.

And again, the posting date does not settle the entire accounting question. A payment reported after month end may relate to a fee earned before month end. Finance still needs to assess that distinction when closing the books.

By this point, the system requirement had become a list of events that all sounded like “the payment date” until we defined them:

• When the debtor made the payment.
• When the client received a direct payment.
• When our company was notified about it.
• When a payment entered the hold queue.
• When it was successfully applied to a valid debtor account.

Those dates answer different questions. A good system can’t collapse them into one field and expect Finance to reconstruct the story later.

There is an irony here. We’re making posting more precise by applying successful payments in real time, but that improvement makes the exceptions more visible: payments we know arrived, but can’t yet attribute and price.

We don’t plan to delay the close until every exception is resolved. We do need to quantify and review the queue, understand later outcomes, and document the basis for any estimate, adjustment, or conclusion that an estimate isn’t supportable.

The warehouse question was never just, “What date did we invoice?” It was, “What event, under the contract, determines the period, and what evidence proves when it happened?”

Payment processing is the same kind of problem. The event is different. The principle is not. Before we automate a process, we need to define what “received,” “held,” “posted,” and “earned” mean and make sure the system records the right event at the right level of precision.

The timestamp doesn’t decide when revenue is earned. It gives us evidence to apply the accounting requirements and support the company’s reported results. Somewhere behind that seemingly small system requirement sits ASC 606.

No, you don’t have to write that reference down. Please just build the milestones that let us apply it.