Your management system holds every policy, transaction and receivable you have — and makes you file a report request to see any of it. CoverQuery lets you just ask, in plain English, and shows you the SQL it ran.
SELECT c.carrier_name_current, COUNT(*) AS policies, SUM(p.premium_amount) AS written_premium FROM policy p JOIN ref_carrier c ON c.carrier_code = p.carrier_code CROSS JOIN v_as_of a WHERE p.is_current = 1 AND c.carrier_type = 'carrier' -- excludes fees AND (p.renewal_date IS NULL OR p.renewal_date >= a.as_of_date) GROUP BY c.carrier_name_current ORDER BY written_premium DESC;
A general-purpose "chat to your database" tool points an LLM at raw tables and hopes. Brokerage systems are full of traps that return a confident wrong number instead of an error. CoverQuery is built around the ones we found in yours.
Agency bill versus direct bill. Aged receivables. Renewal pipeline. Commission splits across producers. Written premium by line of business. The words you already use in the office are the words it answers to.
One adapter per management system translates your data into a single clean model. Everything above that layer — the questions, the answers, the reports — works the same no matter which system you run.
You see the exact SQL that produced the number, in plain sight, every time. Check it, save it, hand it to your accountant. No black box, and no wondering whether the figure on the screen is the one you meant to ask for.
Four real questions, the real SQL CoverQuery generates, and the shape of what comes back. Client names and balances are illustrative; the ledger figures in the last one are real.
"Who's up for renewal in the next 90 days?"
SELECT party_name, policy_number, line_of_business, renewal_date, days_to_renewal FROM v_renewal_pipeline ORDER BY days_to_renewal;
"Next 90 days" counts from your last data sync, not today's date — so a stalled overnight load can't quietly report an empty pipeline.
| Client | Line | Days |
|---|---|---|
| HOLLAND, M. | HABL | 3 |
| REDPATH FARMS LTD | COMM | 11 |
| OKONKWO, A. & J. | AUTO | 24 |
| BRIAR LANE RENTALS | COMM | 57 |
587 policies · illustrative rows
"Who owes us money, and how far behind are they?"
SELECT party_name, balance, bucket_0_30, bucket_31_60, bucket_61_90, bucket_90_plus FROM v_ar_aging ORDER BY balance DESC;
Balances are summed from transaction amounts, never from the ledger's running-balance column — adding that column up returns a number roughly 380× too large.
| Client | Balance | 90+ |
|---|---|---|
| KEELER LOGISTICS | $50,726 | — |
| TREMBLAY, N. | $20,979 | $26,803 |
| FAIRWEATHER, P. | $17,028 | $17,028 |
| DUNMORE HOLDINGS | $8,127 | $8,082 |
97 clients carrying a balance · illustrative rows
"What's covered on this client's vehicles, and what are the limits?"
SELECT risk_description, coverage_code, coverage_desc, limit_amount, deductible_amount, premium_amount FROM v_coverage_detail WHERE party_name LIKE 'OKONKWO%' AND item_type = 'vehicle';
Auto coverage is stored across dozens of columns per vehicle rather than as rows. The adapter reshapes it once, so a coverage question is a coverage question.
| Vehicle | Cov | Limit |
|---|---|---|
| 2019 HONDA CR-V | BI | $2,000,000 |
| 2019 HONDA CR-V | COLL | $500 ded. |
| 2019 HONDA CR-V | COMP | $250 ded. |
| 2014 FORD F-150 | BI | $1,000,000 |
Limits, deductibles and premium per coverage
"Have any of our month-end ledgers stopped balancing?"
SELECT period_end, assets - liability AS balance_sheet_gap, debits - credits AS trial_balance_gap FROM gl_control_period WHERE is_balanced = 0 ORDER BY period_end;
Nobody asked this question for five years, because until now there was no way to ask it. Every one of these months closed and was signed off.
| Month end | Balance sheet | Trial balance |
|---|---|---|
| 2019-11-30 | -0.04 | -0.04 |
| … 10 more months | -0.04 | -0.04 |
| 2020-10-31 | -0.20 | -0.20 |
| … 42 more months | -0.20 | -0.20 |
54 of the last 64 months did not balance.
Two separate breaks — November 2019 and October 2020 — neither ever corrected. The second was added on top of the first.
Four cents is not the problem. Not knowing for five years is.
Your management system stays exactly where it is and keeps working exactly as it does. CoverQuery reads a copy.
Applied Epic or Power Broker, on your server. Untouched, read-only, no plugin installed into it.
Overnight, a copy is translated into one clean model — clients, policies, coverages, transactions, receivables.
Plain English in, an answer and the SQL behind it out. Export it, or save the question and re-run it next month.
Your staff keep working in the system they know. This sits beside it.
Because a copy is taken nightly, you can ask what changed between two dates — something most brokerage systems can't answer at all.
Orphaned records, unresolvable carrier codes, implausible dates and ledgers that don't balance are surfaced, not silently absorbed — see the last example above.
This is your clients' personal and policy information. The controls below are what the system actually enforces, not aspirations.
The database login CoverQuery uses has read permission and nothing else. Even a query that tried to change your data would be refused by the database itself.
Generated SQL is checked before it runs: a single statement, a SELECT only, no chaining, no stored procedures. Anything else is blocked rather than executed.
Social insurance numbers, driver's licence numbers and dates of birth are held back from generated queries unless someone with the right permission explicitly asks for them.
Row limits and query timeouts on every request, so nothing can run away with your server. Every question and the SQL it produced is retained for audit.
Handling a brokerage's book off-premises carries obligations under PIPEDA. Any deployment is covered by a written data processing agreement setting out encryption in transit and at rest, retention and secure disposal, and a breach notification path — agreed before a single record is copied.
The fastest way to judge this is to bring a question your current reporting can't answer, and watch it get answered against your own book.