ABOR and IBOR, and why most systems keep them apart

The short version

The accounting book of record is the official set of books. It is what the auditor examines, what the administrator strikes NAV from, and what the financial statements are built on. It follows an accounting basis, respects period boundaries, and is deliberately conservative about recognizing things that have not happened yet.

The investment book of record is the position view the investment team works from. It answers a different question: what do we own right now, including the trade executed twenty minutes ago that will not settle until Wednesday, and the corporate action that has been announced but not paid.

Both are correct. They disagree because they are answering different questions on different clocks, and the disagreement is not a defect. The defect is what most firms have to do about it.

Why they diverge

Four sources of difference account for nearly all of it.

A worked example makes it concrete. You buy a position on Monday, settling Wednesday, and the month ends Tuesday.

The investment book shows the position on Monday, because you own the economic exposure from the moment the trade is executed. The accounting book shows it on Monday too if your policy is trade date, or on Wednesday if it is settlement date, which means the position lands in the following month and the month-end statements do not include it. Neither answer is wrong. They are answers to different questions, and both are defensible under the right policy.

Why the split became architectural

The reason is historical rather than principled, which is what makes it worth questioning.

Accounting systems were built for periodic close. They were batch-oriented, designed around a monthly cycle, and optimized for producing a defensible answer slowly. That was the right design when the alternative was paper.

Front offices needed something the accounting system could not give them: a position view that was current as of this morning, not as of last month end. So a second system grew up beside the first, fed by the same trade files, keeping its own version of the truth.

Once two systems hold overlapping data, a third thing appears whether anyone designed it or not: the reconciliation between them. And because that reconciliation is genuinely hard, an industry grew around it. For a number of vendors, the reconciliation is not a cost of the architecture. It is the product.

What the split actually costs

A break list that never reaches zero

Every operations team that runs this architecture has a break list, and the break list is never empty. Some breaks are real and matter. Most are timing differences that will resolve themselves in two days. The cost is not the breaks, it is that real problems hide among the noise, and people stop reading a list that has cried wolf for six months.

You cannot answer the obvious question

"What is our NAV right now?" is a reasonable question and, in a two-system architecture, an unanswerable one. The accounting book knows as of the last close. The investment book knows positions but not the accounting treatment. Producing a current number means a person assembling it, which means it arrives late and carries no assurance.

Nobody can say which one is right

This is the corrosive one. When the two books disagree by a material amount and the answer is needed today, someone has to adjudicate. That person is usually the most senior operations person available, and their judgment is not auditable. Over time the organization learns which book to trust for which question, and that knowledge lives in people rather than in the system.

The alternative, and what it actually requires

The alternative is to stop treating them as two books and start treating them as two views of one event stream. Every economic event is recorded once. Trade date and settlement date become lenses over the same journal entries rather than separate databases. The accounting view applies period boundaries and recognition policy; the investment view does not. Neither holds data the other lacks.

Under that design the reconciliation is not automated. It is structurally impossible, because there is nothing to reconcile. That is a categorically different claim from "our reconciliation is very good", and it is worth being precise about which one a vendor is making.

It is also genuinely harder to build, and honesty requires naming why.

• Every event must journalize at one chokepoint. The moment one path writes positions without writing journal entries, you have two books again and you will not notice for a month.
• The dimensions have to be rich enough for both audiences. Entity, fund, class, series, sleeve, currency, counterparty, custodian. If the accounting model is thinner than the investment model, the investment view has to be rebuilt somewhere else, and you are back where you started.
• Close has to seal without freezing. A closed period must be immutable for reporting while the current view keeps moving. Getting this wrong in the safe direction gives you a system nobody can use intraday.
• The agreement needs continuous proof. If the two views agree by construction, that property should be checked continuously rather than assumed, because construction arguments fail quietly.

Four questions for a vendor

If you are evaluating platforms, these separate the architectures faster than a feature matrix will.

1. Where does the reconciliation between your accounting and position data live? If there is one, they are two systems. That may still be the right purchase, but you should know what you are buying.
2. When the two disagree, which one is authoritative, and who decides? A good answer names a rule. A bad answer names a person.
3. Can you strike a NAV as of right now, not as of last close? Ask to see it done in the demo rather than described.
4. What checks that the books are internally consistent, and how often does it run? "Our architecture guarantees it" is an assertion. "These invariants run continuously and here is today's output" is evidence.