Invoicing, AR & commissions

A receivable position that is one current number.

Invoicing and payment plans across direct, agency and list bill, AR aging computed from due dates at read time, payments that are reversed by reference rather than edited, and commission accrual you can re-derive from the record.

Book a demoSee the platformInteractive demo
app.aegisnow.ai/ledger

Billing Command Center

Live

Collected rate

98.4%

↑+1.2pts

AR > 60 days

$2.1M

↓-$0.8M

Reversals on record

traced

Commissions settled

$8.9M

On-time collection rate, last 10 cycles

Trend

AegisNow Billing & Collections is the receivables engine for insurance: invoicing across direct, agency and list-bill arrangements with instalment schedules, an AR aging position computed from due dates rather than stored, payments recorded against their invoice with reversal by reference so cash history is never rewritten, and commission accrual held as basis and rate so the amount is reproducible. Claim money-out runs on the same canonical ledger, writing the payment, the GL posting and the disbursement from one transaction.

0stored aging buckets — every one is computed

Illustrative outcome. We will map Billing & Collections to your own data, frameworks and targets in a working demo.

Why teams choose it

The case for Billing & Collections

Collect every premium, settle every commission, on time.

Aging computed, never stored

An invoice's aging bucket is derived from its due date at read time — a stored bucket is a number that was true once and then silently rots.

Cash history that cannot be rewritten

A reversal is a new row pointing at the payment it reverses, with its reason. Originals are never edited, so a bounced cheque leaves the true story.

Partial payment is a position

Invoices hold amount and amount paid separately, so what is outstanding is a difference rather than a third number that can drift.

Commission you can re-derive

Basis and rate are both stored, so the amount is reproducible from the record when a producer asks why the figure is what it is.

Claim money on the same ledger

A claim payment writes the payment, the GL posting, the disbursement and the reserve movement from one transaction.

One source for screen and report

Reports are queries over the live tables, not a warehouse copy that ages differently from the ledger it was taken from.

Inside the module

Capabilities that ship on day one

Every capability runs on the shared data fabric, the governed Cortex brain and the evidence ledger — so Billing & Collections compounds with the rest of the platform.

Invoicing & instalment schedules

Invoices carry issue date, due date, amount and amount paid — so a partial payment is a position, not a rounding problem.

Learn more

AR aging computed from due dates

Aging buckets are a function of the due date and status, not a column someone maintains.

Learn more

Payments with reversal on the record

A reversal points at the payment it reverses and carries its reason, so cash history is never rewritten.

Learn more

Commission accrual & settlement

Commission accrues as basis times rate against a named producer and policy, then settles as an explicit act.

Learn more
app.aegisnow.ai/ledger

Billing Command Center

Live

Collected rate

98.4%

↑+1.2pts

AR > 60 days

$2.1M

↓-$0.8M

Reversals on record

traced

Commissions settled

$8.9M

On-time collection rate, last 10 cycles

Trend

Claim disbursements on the same ledger

Money out for claims produces the payment, the GL posting and the disbursement from one write.

Learn more

Billing accounts & policy linkage

Every invoice reaches back to the policy and account it was raised against.

Learn more

Collections working view

The desk works from live invoices, live aging and live payments — not last night's extract.

Learn more

Receivables reporting

Collected position, aging distribution and commission summary from the underlying rows.

Learn more
Capability detail

What each capability actually does

Each section below is directly linkable, so a specific answer can be cited on its own rather than buried in a page.

Capability 01

Invoicing & instalment schedules

Invoices carry issue date, due date, amount and amount paid — so a partial payment is a position, not a rounding problem.

An invoice is a record with an issue date, a due date, an amount and an amount paid, which is what makes partial payment a first-class state rather than something reconciled by hand. A policy billed in instalments produces a schedule — annual, semi-annual, quarterly, monthly or EFT monthly — with the down payment and each instalment amount computed from the written premium rather than typed in.

Because the invoice tracks amount and amount paid separately, the outstanding position on any account is derivable at any moment instead of being a month-end exercise. Status and the two amounts together answer the three questions a collections desk actually asks: what was billed, what came in, and what is left.

Instalment schedules come from the same policy servicing engine that computes cancellations and refunds, so the premium an instalment is derived from is the premium the policy actually carries — including after a mid-term endorsement changes it.

What it does

  • Hold issue date, due date, amount and amount paid on every invoice, so partial payment is a tracked position.
  • Build instalment schedules — annual, semi-annual, quarterly, monthly, EFT monthly — with the down payment and per-instalment amounts computed.
  • Derive the outstanding balance from billed less paid rather than maintaining a separate figure.
  • Take the premium basis from the same servicing engine that computes cancellation refunds.

Implements

  • Instalment plans: annual → EFT monthly
  • Invoice states with partial payment

See it in the product

Pay part of an invoice and look at the row: amount and amount paid are both held, and the outstanding figure is the difference rather than a third stored number that can drift.

Capability 02

AR aging computed from due dates

Aging buckets are a function of the due date and status, not a column someone maintains.

The aging bucket an invoice falls into is computed from its due date and status every time it is asked for. That sounds small and is not: a stored bucket is a number that was true once and silently rots, and an AR report built on stored buckets tells you what was overdue whenever the job last ran.

The aging summary aggregates the live book — current, and the overdue bands beyond it — so the receivable position is one current number rather than a reconciliation between a ledger and a report.

The collections view is built on that same computation. It reads invoices, the aging summary and payments from the API rather than a snapshot, so what a collector works from is the book as it stands.

What it does

  • Compute an invoice's aging bucket from its due date and status at read time.
  • Aggregate a live aging summary across the book rather than reporting a stored snapshot.
  • Serve the collections view from the same live figures, so the desk and the report cannot disagree.

Implements

  • Current and overdue aging bands
  • Read-time bucket derivation

See it in the product

Open Collections under Billing. The aging summary and the invoice list come from the same live computation — move an invoice past its due date and the bucket changes without a job running.

Capability 03

Payments with reversal on the record

A reversal points at the payment it reverses and carries its reason, so cash history is never rewritten.

Payments are recorded against the invoice they settle with their method — EFT, cheque, card, ACH or lockbox — a payment number, the amount, and the user who recorded them. Method is captured because the channel matters to reconciliation, not because it changes the accounting.

The part worth pointing at is reversal. A reversing payment carries a pointer to the payment it reverses and the reason for it, rather than the original being edited or deleted. That means a bounced cheque, a duplicate application or a misapplied receipt leaves two rows telling the true story instead of one row that quietly changed. Cash history is append-only by construction.

One thing this deliberately does not claim: cash is not auto-applied. Recording a payment requires the invoice it belongs to. There is no matching engine reading a lockbox file and deciding which receivable a payment settles, and no exception queue for the ones it could not decide. Building that is real work with a bank file format at the other end of it, and until it exists the platform records applied cash accurately rather than implying it matched it.

What it does

  • Record each payment against its invoice with method, payment number, amount and the user who recorded it.
  • Support EFT, cheque, card, ACH and lockbox as recorded methods.
  • Record a reversal as a new row pointing at the payment it reverses, with its reason.
  • Never edit or delete an original payment, so cash history stays append-only.

Implements

  • Payment methods: EFT, cheque, card, ACH, lockbox
  • Reversal by reference, not by edit

See it in the product

Reverse a payment and look at both rows: the reversal names the payment it reverses and why, and the original is unchanged. Then note what is absent — no auto-matching, because applying a payment requires naming its invoice.

Capability 04

Commission accrual & settlement

Commission accrues as basis times rate against a named producer and policy, then settles as an explicit act.

A commission record holds the policy, the producer, the basis amount, the rate percentage and the resulting amount, with a status and the moment it accrued. Accrual is therefore reproducible: the amount is basis times rate, both stored, so a producer asking why a figure is what it is gets an answer from the record rather than a recalculation someone has to trust.

Settlement is a separate, explicit act against a specific accrual rather than a bulk state change, which keeps earned and paid distinguishable at the record level. The commission summary reports the position across producers from those same rows.

Stated plainly, because the previous version of this page did not: this is accrual and settlement, not a full compensation engine. There are no tier ladders, no hierarchy overrides and no clawback mechanics in the model — the record carries one basis and one rate. Schedules with graded tiers, agency overrides on sub-producer production, and chargebacks on early lapse are all real requirements this does not yet meet, and they are compensation-plan features rather than a different way of storing what is here.

What it does

  • Hold basis amount, rate percentage and resulting amount on each accrual, against a named producer and policy.
  • Make the amount reproducible as basis times rate from the stored figures.
  • Settle a specific accrual as an explicit act, keeping earned and paid distinguishable per record.
  • Report the commission position across producers from the accrual rows themselves.

Implements

  • Basis × rate accrual per producer and policy
  • Per-record settlement

See it in the product

Open a commission record: basis, rate and amount are all present, and the amount is the product of the other two. Settle it and the status changes on that record alone.

Capability 05

Claim disbursements on the same ledger

Money out for claims produces the payment, the GL posting and the disbursement from one write.

Claim payments and premium receivables are not separate financial worlds bolted together. A claim payment writes through a canonical ledger that also produces the general-ledger posting and the disbursement record, so the money movement, the accounting entry and the payee instruction come from one transaction rather than three systems reconciling later.

That is what makes a claim's paid figure and the accounting behind it the same fact rather than two views that agree most months. The disbursement is the payee instruction; the GL posting is the accounting; the payment is the event — and they are written together or not at all.

The same transaction draws the claim's reserve down as a typed movement on the reserve ledger, which is why incurred stays equal to paid plus reserve without a nightly job to enforce it.

What it does

  • Write the claim payment, the GL posting and the disbursement in one transaction.
  • Draw the claim reserve down as a typed ledger movement in the same transaction.
  • Keep incurred equal to paid plus reserve without a reconciliation job.
  • Hold claim money-out and premium money-in on the same financial substrate.

Implements

  • Canonical payment ledger with GL postings
  • Disbursement as payee instruction

See it in the product

Pay a claim and follow the write: a payment, a GL posting, a disbursement and a reserve movement, all from the one transaction.

Capability 06

Billing accounts & policy linkage

Every invoice reaches back to the policy and account it was raised against.

Invoices are raised against a billing account and a policy, so the receivable is traceable in both directions: from an account to everything it owes, and from a policy to everything billed on it. That linkage is what lets a servicing question and a collections question be answered from the same record.

Because policy administration and billing share the policy, a mid-term change that alters premium is visible to billing as a change to the thing being billed rather than as a manual adjustment someone remembers to make.

Payments, commissions and invoices all carry the policy identifier, which means the financial history of a policy is assemblable without joining across systems that each hold part of it.

What it does

  • Raise invoices against a billing account and a policy, traceable from either direction.
  • Share the policy record with policy administration rather than mirroring it.
  • Carry the policy identifier on payments and commissions as well as invoices.

Implements

  • Billing account to policy linkage
  • Shared policy record with policy administration

See it in the product

From a policy, list its invoices, its payments and its commission accruals — all reachable by the same identifier rather than reconciled by policy number strings.

Capability 07

Collections working view

The desk works from live invoices, live aging and live payments — not last night's extract.

The collections view reads invoices, the aging summary and payments from the API at request time. A collector therefore works the book as it is, and a payment recorded a minute ago is visible rather than waiting for a refresh cycle.

Payments can be recorded from the same view against the invoice being worked, which keeps the action next to the context that prompted it.

What is deliberately absent, and was previously claimed: there is no dunning engine. There are no configurable dunning sequences, no lapse-risk-weighted escalation and no automated non-pay cancellation workflow. The overdue position is computed and visible; the decision about what to send and when is a human one made outside the platform, and the page should not suggest otherwise.

What it does

  • Read invoices, aging and payments live at request time rather than from an extract.
  • Record a payment against the invoice being worked, from the same view.
  • Show the computed overdue position without claiming an automated escalation path.

Implements

  • Live receivable position
  • Manual collections decisioning

See it in the product

Record a payment in Collections and re-read the aging summary: the position has moved, because both come from the same live figures rather than a cached report.

Capability 08

Receivables reporting

Collected position, aging distribution and commission summary from the underlying rows.

Reporting is built on the same rows the operational views read, so a figure in a report and a figure on a screen have one source. The aging distribution comes from the computed buckets; the collected position comes from billed against paid; the commission summary comes from the accrual records themselves.

This matters more than it sounds, because the common failure in billing reporting is a warehouse copy that ages differently from the ledger. Reports here are queries over the live tables rather than a second representation that has to be kept honest.

Exports carry the same figures, so a spreadsheet handed to finance and the screen a collector is looking at do not diverge on the way out of the system.

What it does

  • Report the aging distribution from the same computed buckets the operational views use.
  • Derive the collected position from billed against paid rather than a stored rate.
  • Build the commission summary from accrual rows rather than a parallel aggregate.
  • Export the same figures the screens show.

Implements

  • Reporting over live tables
  • One source for screen and report

See it in the product

Compare the aging summary on screen with an export taken at the same moment — they are the same query, so they cannot disagree.

Built for the people who own the risk

Made for your team, aligned to your frameworks.

Cortex skill-agents draft the work, cite their sources and write every action to the evidence ledger — so Billing & Collections accelerates the people accountable for it without putting your audit posture at risk.

Who it serves

  • Billing operations leaders
  • Finance & controllers
  • Collections teams
  • Commission accountants
  • Agency operations

Aligned to

  • State non-pay cancellation rules
  • NAIC model laws
  • PCI DSS (payments)
  • SOX-aligned controls
  • GAAP / IFRS revenue timing
CortexAI reasoning copilot
Grounded

Shared device fingerprint with the ring94
Repair shop tied to a prior SIU case87
Loss pattern matches the closed cluster81
SourcesPolicy ledgerClaims graphSIU casebook
Confidence94%
Works better together

Pairs with the rest of the platform

Billing & Collections shares one core with every other module — combine it to extend coverage without adding integration debt.

Policy Administration

Service the book, launch products and run MGA programs on one core.

Distribution & Agency

Onboard, license, pay and grow your producer force.

Customer 360

One view of every policyholder, household and interaction.

Cortex AI

AI that drafts and assists across insurance — but never decides ungoverned.

For your industrySee how Billing & Collections works in regulated sectors.
Personal & commercial lines carriers

P&C Insurance

Quote-to-claim on one core, with the combined ratio in view.

Explore P&C InsuranceLife, annuity & retirement carriers

Life & Annuities

From accelerated underwriting to automated death claims.

Explore Life & AnnuitiesMGAs, MGUs & coverholders

MGAs & Program Administrators

Bind inside authority, report on time, win more capacity.

Explore MGAs & Program Administrators
FAQ

Billing & Collections FAQ

What evaluation teams want to know before a demo — answered plainly.

Direct bill, agency bill and list bill, each with instalment schedules, down payments and autopay — all posting to a single premium ledger so the receivable position is always current and reconciled.

No, and the page previously said otherwise. There are no configurable dunning sequences, no lapse-risk-weighted escalation and no automated statutory non-pay cancellation notices. What exists is a computed, live overdue position — an invoice's aging bucket is derived from its due date at read time — and a collections view that works from it. What to send and when is a human decision made outside the platform.

Accrual and settlement, stated plainly. A record holds the policy, producer, basis amount, rate percentage and resulting amount, so the figure is reproducible as basis times rate; settlement is an explicit act against a specific accrual, which keeps earned and paid distinguishable per record. There are no tier ladders, no hierarchy overrides and no clawback mechanics — those are compensation-plan features this does not yet have, not a different way of storing what it does.

No. Recording a payment requires naming the invoice it settles. The method is captured — EFT, cheque, card, ACH, lockbox — because the channel matters to reconciliation, but there is no engine reading a bank file and deciding which receivable a receipt belongs to, and no exception queue for the ones it could not decide. What is guaranteed is that applied cash is recorded accurately and reversibly.

Payments are append-only: a correction is a reversal row pointing at the payment it reverses, carrying its reason, rather than an edit to the original — so a bounced cheque or a misapplied receipt leaves the true story in two rows. Claim money-out writes the payment, the GL posting and the disbursement from one transaction, so the accounting and the event are the same fact. One limit: approval thresholds on write-offs are not implemented, because there is no write-off workflow in the model at all.

See Billing & Collections on your data

Book a working session and we will map your sources, workflows and frameworks onto Billing & Collections — and show Cortex reasoning over them live.

Book a demoExplore the platformInteractive demo
Billing & Collections — Collect every premium, settle every commission, on time. | AegisNow Insurance