By module
Finance & the ledger
iqava has one general ledger, and every module posts into it automatically. No parallel subledger to reconcile — the technical and the financial books are the same book.
Best use case
The connected core — money follows the bind
Domain actions emit events; built-in subscribers turn them into real, balanced, POSTED journals, idempotent per source record (so re-firing never double-posts). A few of the automatic postings:
- Policy bind → the debit note: receivable (grossed up) / gross written premium + statutory levies payable.
- Cession / retrocession confirmed → reinsurance premium ceded / reinsurance payable.
- Facultative bound → assumed premium (net + commission).
- Claim reserved → claims incurred / reserve (the movement; a release reverses it).
- Broker placement bind → brokerage income, and the client-money pass-through (IBA).
- Bancassurance → channel commission expense / payable.
Tip
Booking codes — the Credit-Control handoff
When business is booked (a policy, treaty, programme or facultative binds) the system issues a searchable booking code (BKP- / BKR- / BKB- / BKF-). Credit Control finds the business by code and processes its accounting — the real-world id-driven handoff between underwriting and finance.
Cash management & reconciliation
Open-item AR/AP with aging, settlements and netting (with their GL postings), a cash position across accounts, and bank reconciliation with an AI assistant that proposes matches (direct, bank-charge, one-to-many) for unmatched lines.
IFRS 17
Measurement on the same data, two models:
- PAA(short-duration / most P&C) — LRC released to revenue by passage of time, LIC at fulfilment cash flows, and an onerous test that recognises a loss component immediately.
- GMM (long/life) — fulfilment cash flows + risk adjustment + CSM, rolled forward with accretion and released by coverage units, split onerous / profitable.
- VFA (direct participating) — for contracts where the policyholder shares in a pool of underlying items and you keep a share of the return on it. That share is your variable fee, and because it is the price of future service a movement in it adjusts the CSM rather than going straight to profit.
On a participating group you record the fair value of the pool and your share of it. Each period you give the closing fair value and iqava works out the fee, adjusts the CSM by it and releases by coverage units as usual. There is no accretion line: the return on the pool already carries the financial effect, so accreting as well would count it twice. If the pool falls far enough to wipe out the CSM, the group is flagged as having turned onerous rather than being allowed to run negative.
If you hedge the financial risk you have promised away, the risk mitigation option lets a share of the fee bypass the CSM and go to profit instead, so it lands in the same place as the hedge it matches. Set it as a percentage on the group. It is a policy choice and applies from the day you set it, not backwards. iqava also refuses the VFA where the standard does: never on reinsurance held, and not without a real pool and a real share.
Give a group a coverage schedule (how many periods, how often, and whether cover is level, front loaded or back loaded) and it also gets two things. A revenue schedule showing the liability released to revenue each period, discounted and undiscounted, with the unwind of the discount as the insurance finance expense. And automatic release: the period label, the coverage units provided and the units still to come are all worked out for you, so each quarter you confirm a release rather than retype the units. The last period releases whatever is left, so the CSM finishes at nil.
Valuing the life fund
Endowment and life savings policies are valued on a mortality table, not just accumulated. Set the basis once on the actuarial page: the table, the rate of interest, the Zillmer adjustment, the lapse rate, the expense assumptions and the surrender value scale. Changing it is audited, because moving the rate of interest moves every reserve in the fund.
On the mortality table itself: iqava ships two Makeham laws, which are formulas anyone can state and which are fine for illustration and for pricing conversations. A statutory valuation has to be done on the table your regulator prescribes, and those tables belong to the bodies that publish them, so iqava does not ship them. Paste yours into the mortality tables card, pick it in the valuation basis, and every reserve from that moment is valued on it. The paste box reads whatever shape the table arrives in: age and rate side by side, a bare column of rates, or the survivorship column. It tells you what it understood and shows you the rates and the expectation of life at a spread of ages, which is the plainest check there is that the right table went in.
What gets booked to the life fund is the Zillmerised net premium reserve, which spreads the initial expense over the premium term instead of writing it off at once. Alongside it the policy page shows the gross premium reserve on a double decrement basis, the new business strain, and the asset share: what the policy has actually accumulated. If the asset share does not cover the maturity benefit, the page tells you, because that means the bonuses being declared are running ahead of what the policy has earned.
A policy needs an age at entry to be valued this way. Without one it is held at its accumulated fund value and the page says so, with what to fix.
Best practice
Deep reference: the chart of accounts and event→posting matrix are in the repo docs (docs/domain/connected-core-accounting.md). · Documentation overview