IBOR vs ABOR Reconciliation
The daily process of comparing the forward-looking investment book of record (IBOR) against the custodian-confirmed accounting book of record (ABOR) to identify and resolve position differences arising from the settlement cycle.
Definition
The investment book of record (IBOR) and the accounting book of record (ABOR) represent the same economic positions observed at different stages of the settlement lifecycle. They diverge in timing, purpose, and legal standing, creating a reconciliation requirement that defines the daily workflow of the middle and back office.
Side-by-side comparison
Side-by-side comparison
| IBOR | ABOR | |
|---|---|---|
| Full name | Investment Book of Record | Accounting Book of Record |
| Update trigger | Trade execution | Custodian settlement confirmation |
| Unsettled trades | Included | Excluded |
| Accruals | Estimated | Confirmed |
| Corporate actions | On announcement or ex-date | On custodian confirmation |
| Primary users | Portfolio managers, traders, risk systems | Fund accountants, administrators, auditors |
| Use cases | Investment decisions, compliance, intraday risk | NAV calculation, financial statements, regulatory filing |
| Valuation | Real-time or intraday prices | End-of-day custodian or administrator prices |
| Settlement basis | Expected positions | Settled positions only |
| Audit standing | Operational record | Legally recognized accounting record |
The IBOR is the portfolio manager's operating view. It reflects positions as of trade execution: when a buy or sell is committed to, the IBOR changes immediately. It captures everything the investment team has committed to own or sell, regardless of whether those commitments have been discharged through settlement. Pre-trade compliance checks, intraday risk monitoring, cash management, and order management system integration all depend on the IBOR reflecting the portfolio's current expected state, including trades that will not settle until tomorrow.
The ABOR is the accountant's and auditor's view. It reflects positions as of custodian confirmation: only after a trade has settled and the custodian has confirmed delivery versus payment does the ABOR record the position change. The ABOR is the legally defensible record used for NAV calculation, audited financial statements, investor reporting, and regulatory filings. Auditors, regulators, and investors rely on it precisely because it is based on confirmed events.
The difference between the two books on any given day is the settlement gap: trades executed and in the IBOR that have not yet settled and therefore are not yet in the ABOR. Additional differences arise from:
- Corporate actions processed on different timelines in each system
- Accruals recognized in the ABOR but not the IBOR
- FX revaluation applied at different rates or cutoffs
- Manual adjustments made in one system without a corresponding entry in the other
The settlement gap is not a deficiency. It is the normal consequence of the trade lifecycle. The IBOR-ABOR reconciliation is the operational control that distinguishes expected, in-window differences from genuine problems.
The three-book framework
IBOR and ABOR are joined by a third record in many institutional operations models: the performance book of record (PBOR). The PBOR extends the IBOR with return calculation, performance attribution, and benchmark comparison data. It converts position and valuation information into the performance metrics used for client reporting and GIPS compliance.
Together, the three books form the complete position data architecture:
- IBOR feeds the investment process
- ABOR feeds financial reporting
- PBOR feeds investor reporting and performance attribution
The quality of IBOR-ABOR reconciliation directly affects the PBOR. An unresolved break that distorts the ABOR will propagate into performance calculations until corrected.
From reconciliation to integration
The dominant trend in institutional operations through 2025 and into 2026 is a shift away from managing the IBOR-ABOR gap through daily reconciliation toward eliminating the gap through architectural integration. The daily reconciliation cycle is increasingly framed as operational reconciliation overhead — permanent labor that exists only because IBOR and ABOR are maintained in separate systems with separate data pipelines.
The key technology drivers are:
- Unified data architecture: IBOR and ABOR become views of the same underlying event log, updated from the same settlement events, rather than outputs of separate systems compared after the fact
- AI-assisted reconciliation: machine learning models identify systematic break patterns and automatically apply corrections, reducing manual reconciliation effort by documented margins
- Distributed ledger technology: a blockchain settlement event visible simultaneously to all parties provides a shared update trigger for both the IBOR and ABOR, eliminating the custodian confirmation lag
For digital asset positions settling on-chain, the ABOR update is triggered by a deterministic or protocol-defined finality event rather than a custodian statement, compressing the settlement gap to seconds rather than hours.
How it works
The reconciliation workflow
The IBOR-ABOR reconciliation runs daily, timed to the custodian's end-of-day statement delivery. The workflow has six stages:
Extraction: pull position snapshots from both the IBOR and ABOR at a consistent reference time. Both snapshots must reflect the same cutoff. An IBOR snapshot at 4:00 PM compared against an ABOR snapshot from an earlier custodian statement will produce phantom breaks from activity in the intervening window.
Normalization: map positions across the identifier schemes and account hierarchies each system uses. The IBOR may use internal security identifiers or OMS instrument IDs; the ABOR uses ISIN, CUSIP, or SEDOL as received from the custodian. Account structures may also differ: the IBOR holds positions at the strategy or sleeve level; the ABOR consolidates at the fund level. Reconciliation requires a maintained mapping layer before comparison is possible.
Comparison: run position comparison at the security-and-account level, producing a difference for every line where IBOR and ABOR quantities or values do not match. Tolerance thresholds suppress differences attributable to rounding or minor timing artifacts.
Break identification: flag all differences above tolerance and tag each with the relevant metadata: security, account, quantity difference, value difference, and days since first appearance.
Categorization and routing: classify each break by root cause and route it to the responsible team.
Resolution and sign-off: confirm resolution against the settlement pipeline or escalate unresolved breaks before the NAV calculation cutoff.
Break categories
Break categories
| Break Type | Root Cause | Resolution Path |
|---|---|---|
| Settlement fails | Trade executed, did not settle on expected date | Match against pending settlement pipeline; escalate as active fail if past settlement date |
| Booking errors | Position in IBOR with no corresponding custodian record | Investigate transmission; resubmit or cancel |
| Corporate action discrepancies | Portfolio system and custodian applied same event differently | Reconcile entitlements; correct in one or both systems |
| Pricing differences | IBOR and ABOR use different price sources | Track separately; not a position error |
Settlement fails in detail
Settlement fails are the most common category. Every trade within its normal settlement window appears as an expected settlement difference: these should match the outstanding settlement pipeline exactly. When a fail persists past the intended settlement date, it becomes an active fail requiring intervention. Settlement fails are typically detected through CSD or custodian fail reports — such as those from the Depository Trust and Clearing Corporation or Euroclear — before the end-of-day reconciliation surfaces them independently.
Active fails require direct action: contacting the counterparty, prime broker, or CSD to determine the cause of failure and initiate resolution. Unresolved fails accumulate interest penalties under standard market agreements and may trigger regulatory notification obligations if they persist.
Booking errors in detail
Booking errors indicate a process breakdown rather than a timing lag. A position in the IBOR that has no corresponding custodian record means the trade was either never transmitted to the custodian or was silently rejected at transmission. Unlike settlement fails, there is no pending settlement to wait for. Booking errors require immediate investigation because they represent positions the investment team believes it owns that the custodian has no record of.
The NAV dependency
The hard deadline for break resolution is the NAV calculation cutoff. Fund administrators proceed from the ABOR once the daily custodian reconciliation is complete and material breaks are resolved or explained. An unresolved material break means the ABOR positions may be incorrect, and the NAV may be struck on inaccurate data. This makes IBOR-ABOR reconciliation a financial reporting control, not just an operations metric.
T+1 and the compression of the reconciliation window
The transition to T+1 settlement for US equities, effective May 2024, changed the operational parameters materially:
- The expected settlement break population shrank: at most one day of unsettled equity trades sits between IBOR and ABOR rather than two
- The resolution window shrank equally: a fail has one day to resolve before settlement, not two
- Reconciliation must run intraday, not overnight
- Counterparty discrepancies must be identified and resolved on trade date
Firms that ran IBOR-ABOR reconciliation as an overnight batch process find that T+1 requires either intraday reconciliation cycles or tighter architectural integration between the two books.
In Devancore™
Devancore approaches the IBOR-ABOR relationship from the integration end of the spectrum rather than the reconciliation end. The IBOR and ABOR within Devancore are not outputs of separate systems compared daily. They are views of the same underlying position and event record, differentiated by settlement status rather than system of origin.
The core architectural principle:
- When a trade executes, the investment position updates immediately in the IBOR view
- When settlement occurs (confirmed by the custodian, DTC, or for digital assets, by on-chain finality), the accounting position updates from the same event record, not from a separate data feed
- The ABOR position is the IBOR position filtered to confirmed, settled transactions
This means the only differences between the two views are expected ones:
- Trades in the settlement window
- Pending corporate action entitlements
- Income accruals not yet paid
Unexpected differences surface as operational exceptions in real time rather than appearing at end of day in a cross-system comparison report.
Reconciliation as pipeline monitoring
The reconciliation workflow in Devancore is a pipeline monitor rather than a table compare. Settlement breaks are identified by querying the outstanding settlement instruction queue against expected settlement dates:
- A break that matches a pending instruction is expected and will resolve at settlement
- A break that cannot be matched to any pending instruction is flagged immediately as a booking error or processing gap
Break categorization runs automatically. Each exception is routed to the relevant operations team with context already assembled: the originating trade, expected settlement date, counterparty, and age of the exception.
Digital assets
For digital asset positions, on-chain settlement events provide a clean ABOR update trigger. When a trade settles on a blockchain with deterministic or protocol-defined finality, the ABOR position updates at confirmation time rather than at the next custodian statement cycle. The settlement gap for on-chain positions is measured in seconds rather than hours. The on-chain transaction hash is recorded as the settlement evidence in the ABOR entry, providing the same auditability as a custodian confirmation.
Ops Copilot
Ops Copilot surfaces the IBOR-ABOR exception queue at the start of each operations session, prioritized by settlement date proximity, break age, and materiality, with resolution history and contextual data already assembled. Material unresolved breaks are escalated automatically before the NAV calculation window. Shadow NAV runs from Devancore's ABOR in parallel with the official administrator NAV, and discrepancies are surfaced before publication: catching pricing errors, missing corporate action entries, or income posting gaps before they reach clients or regulators.