The same sale, in three periods at once

Adding a second payment processor is one of those decisions that looks free. Better rates in one region, a card type the first one doesn't handle well, a backup for when somebody's API has a bad afternoon. Nobody objects. It goes in.

The bill arrives later, and it isn't a bill. It's a slower close.

Three clocks

Here's what changes. One processor gives you one settlement calendar, and after a few months your team internalizes it without writing it down. Sale on Monday, batch cuts at 11pm Pacific, funds land Wednesday. Weekends push to Tuesday. Fine. It's a rhythm, and rhythms are easy to work around.

Two processors give you two calendars that don't line up. Three give you three. And the calendars differ in ways that aren't documented anywhere you'd think to look:

• Batch cutoff times, in whatever timezone the processor decided on. A sale at 4pm in Chicago might land in today's batch on one processor and tomorrow's on another, because one cuts at 11pm Pacific and the other cuts at midnight UTC. Those are the same instant only in summer, and only if nobody changed anything.
• Funding delay, which is T+2 for one, T+1 for another, and "next business day, except we don't count the day of the transaction" for a third.
• Weekend and holiday handling, which is where it gets genuinely silly. Not every processor observes the same holidays. If you're taking money in more than one country, some of your funding calendars have holidays your finance team has never heard of.
• Whether the payout is per-batch or per-day, which sounds like the same thing and is not, because a heavy day can split into two batches and arrive as two deposits, or two light days can be rolled into one.

Which month does it belong to?

Take one sale. Thursday, July 31st, 4:47pm.

Your ledger recognizes it on July 31st, because that's when the customer bought the thing. Correct.

The processor puts it in the August 1st batch, because its cutoff already passed. Also correct.

The money reaches your bank on August 4th. Correct too.

So: what month is that sale in? Depends who you ask, and all three of them are right. This is not a bug in anyone's system. Everyone is measuring a different event — the sale, the batch, the funding — and those events genuinely happened on different days.

For one transaction it's a curiosity. At the end of July, it's every transaction after the cutoff on the last day of the month, across every processor, each with a different cutoff. That's the cluster of items sitting unmatched on the first of the month, and the reason someone is doing this manually at 9pm.

Why matching on order ID doesn't rescue you

The obvious fix is to stop caring about dates and match on identity. Every order has an ID. Match on that.

It works right up until it doesn't, for reasons that are all boring:

Processors assign their own transaction identifiers, and what comes back in the settlement file is often their ID, not yours. If your integration passes a reference through, great — assuming every integration you've ever shipped passed it correctly, including the checkout flow somebody built in a hurry two years ago.

Then there's the many-to-one problem. A single order can be more than one transaction: an authorization, a partial capture, a second capture when the rest of the item shipped, a partial refund. Now one order ID maps to four settlement rows, arriving across three weeks. Which one is "the" match?

And one-to-many, which is worse. Some processors net an entire day into a single payout line. There's no per-transaction row to match against — just a total, and a fee summary, and the assumption that you'll trust the arithmetic.

Chargebacks are their own category of pain. The dispute reference is assigned by the card network, weeks after the sale, and frequently bears no resemblance to anything in your database. Somebody matches those by amount and approximate date, which works fine until you have two customers who bought the same item for the same price in the same week.

What the work actually is

Strip away the tooling and the job is three questions, asked about every line that didn't automatically agree:

1. What is this?
2. Which period does it belong to?
3. What's the entry?

Question one is usually answerable in a few seconds if you have the underlying rows in front of you — the payout line, the original order, the fee schedule, the dispute record. The reason it takes twenty minutes instead is that those four things live in four systems, and you're going to go get each of them.

Question two is judgment, and it's genuinely yours. Different businesses answer it differently, and auditors care about the consistency of the answer more than the answer itself.

Question three follows from the first two and is nearly mechanical.

So most of the time is spent on the part that is pure retrieval — gathering evidence so you can make a call that then takes ten seconds. That's the ratio worth attacking. Not the judgment. The fetching.

The version I'd want

I don't think the answer is software that decides which period a transaction belongs to and posts the entry. I've watched enough automated reconciliation quietly put things in the wrong month to be suspicious of anything that confident, and "the system decided" is not an answer you want to give an auditor.

What I'd want is narrower. Every unmatched line shows up already explained — this is a refund against an order from July 24, here's the original sale, here's the fee row, here's why it's in this batch and not the previous one — with all four source records attached so I can verify the claim faster than I could have found it myself. Then I decide the period. Then it posts, because I said so.

That's a much smaller promise than most reconciliation tools make. It also happens to be the part of the work that eats the week.