An app your firm owns
Clio supports the OAuth 2.0 authorization-code grant and nothing simpler — no API key to paste in. The application is registered in your firm's developer account, authorised by your user, and scoped to read.
Clio Manage practice data to Power BI, done for you
There is no Clio connector in Power BI, so this starts with a real extraction — OAuth against the Clio Manage API, a modelled star schema over matters, activities, bills and payments, and DAX for matter profitability, realization and attorney utilization. Built by a senior US-based engineer, not exported to a spreadsheet every month-end.
Representative dashboard — sample data
Start with the awkward fact
Clio Manage holds the operating truth of a law firm — every matter, every contact, every time and expense entry, every bill, every payment against it — and Power BI cannot see a byte of it out of the box. Clio is not on Microsoft's published list of Power Query and Power BI connectors (opens in new tab), and no third-party connector is going to appear because you need it this quarter. Crossing that gap properly is most of the work; charting what comes out is not.
So the build runs extraction, then modelling, then measures. Register an application in a Clio developer account, run the OAuth handshake against the regional endpoint your firm actually lives on, and page the history once. Flatten matters, contacts, activities, bills and payments into conformed dimensions and facts. Add the date table and the timekeeper cost rates Clio does not hold. Then write the DAX that turns billed hours into realization, margin and aged WIP — numbers a managing partner would put in front of a compensation committee.
What we build from Clio
Buy a block of prepaid Flex hours and, if you're unhappy within the first 4 hours, we refund you in full — no questions asked. Hours are deducted only for work you've reviewed and approved, there's no project minimum, and your banked hours never expire.
What the build covers
Every one sits upstream of the report page, and every one is where a firm's own attempt tends to stop.
Clio supports the OAuth 2.0 authorization-code grant and nothing simpler — no API key to paste in. The application is registered in your firm's developer account, authorised by your user, and scoped to read.
Clio runs separate US, EU, Canada and Australia environments, and a token issued against one is not valid against the others. Confirming your region in scoping avoids an authentication failure that looks like bad credentials.
Without a fields parameter most Clio endpoints hand back only an id and an etag. Each attribute and each related record the model needs is named explicitly, so nothing arrives — or goes missing — by accident.
Index requests cap at 200 records and the API is rate-limited per token. History is pulled in staged batches with cursor paging and backoff — the difference between a refresh that finishes and one that returns a 429.
Worked, billed and collected are three different numbers, and firms disagree about all three. We agree the definitions with you, then write them as separate measures rather than one figure nobody can reconstruct.
Scheduled or incremental refresh, row-level security by attorney, practice group or office, and failures fixed by us out of your banked hours rather than landing on whoever built it.
Through the Clio Manage API v4, because there is no other supported route. Your firm registers an application in a Clio developer account, which issues the key and secret used to run the OAuth 2.0 authorization-code flow; a user with the right permissions authorises it once, and the resulting refresh token is what keeps the extract alive. Clio supports that grant type and no other, so there is no API key to paste into Power BI Desktop and no shared password to rotate.
Two things matter beyond getting a 200 back. First, region: Clio operates separate US, EU, Canada and Australia environments, and a token issued against one endpoint is not valid against another — a mismatch produces authentication errors that read like a credentials problem and are not. Second, ownership: the application and the credentials belong to your firm, and read-only permissions are sufficient for reporting, so nothing we build can alter a matter, a bill or a trust ledger. If your firm already replicates Clio into a SQL database or a warehouse, we model from that copy instead, which usually refreshes faster and is easier to join to payroll.
More than a typical REST source, and all of it is documented rather than discovered. The behaviours below are the ones that decide whether a scheduled refresh completes at 6am or quietly returns a partial dataset, and each one is designed for in the extraction layer rather than patched afterwards.
| API behaviour | What Clio documents | What it means for the build |
|---|---|---|
| Authentication | OAuth 2.0 authorization-code grant only, against an application registered in a Clio developer account | A named user authorises once; refresh tokens are stored and rotated, not a shared login |
| Regional endpoints | Tokens issued against the US endpoint are not valid against the EU, Canada or Australia endpoints | Your region is confirmed in scoping, before a single query is written |
| Sparse responses | Without a fields parameter, most endpoints return only id and etag |
Every attribute and nested relation the model needs is requested explicitly, by name |
| Page size | Index requests return at most 200 records unless otherwise specified | Years of time entries come back in staged batches, not one hopeful query |
| Pagination method | Cursor paging is the default; offset paging is capped at 10,000 records and then errors | Any firm with real history must use cursor paging or the extract stops short |
| Rate limiting | Limited per access token — 50 requests per minute by default at peak — returning 429 with X-RateLimit-Remaining and X-RateLimit-Reset headers |
Throttling and backoff are built into the extract rather than found on the first refresh |
Clio's own developer documentation (opens in new tab) is the source for each of these, and it is worth reading before anyone estimates the work. The sparse-response rule in particular catches people out: a query that looks like it succeeded can return nothing but identifiers, and the mistake surfaces three steps later as an empty visual.
Fewer than firms expect. Almost every question a managing partner asks — which matters made money, who is under-utilised, what is sitting unbilled, who is slow to pay — resolves to some combination of matters, activities, bills and payments hanging off the client and timekeeper records. The table below maps each one to the job it does once the data is modelled rather than exported.
| Record | What it holds | Role in the model |
|---|---|---|
matters |
The central record for legal work: client, practice area, responsible and originating attorney, status, billing method and open and close dates | The grain almost every profitability question resolves to — and the key each fact conforms against |
contacts |
Clients and the people and companies related to them | Client dimension, behind concentration and client-level margin |
activities |
Time and expense entries, each with a date, quantity, rate, billable flag and the user who logged it | Primary fact for worked value, utilization and everything that later becomes WIP |
bills and line items |
What was actually invoiced, including discounts and write-downs at invoicing | Fact for billed value — the numerator and denominator of both realization measures |
| Payments and their allocations | Receipts and how each one settles against specific bills | Fact for collected value, collection realization and days-to-pay |
users |
Timekeepers, their roles and their rate history | Timekeeper dimension, joined to the cost-rate table your firm supplies |
practice_areas |
The firm's practice groups as configured in Clio | Grouping dimension for margin, leverage and partner reporting |
custom_fields |
Firm-defined fields on matters and contacts — referral source, fee arrangement, internal case codes | Whatever your firm has quietly made load-bearing, documented during scoping |
tasks and calendar_entries |
Deadlines, hearings and appointments tied to a matter | Activity fact behind capacity and leading indicators rather than lagging results |
Two structural details cause most of the rework. Rates are the first: an activity carries the rate it was logged at, and that is the rate the model must use — pulling today's rate card against five years of history quietly rewrites the past. Custom fields are the second. Most firms have repurposed them to carry something meaningful, and nothing in the API tells you that a field named Text 4 means "fee arrangement". Both get documented in scoping and conformed into a star schema before any measure is written.
In DAX, over that star schema, against a date table covering the full history. The measures below are the ones argued about in every legal engagement, because each embeds a definition firm leadership has to agree with before the number means anything. We write them explicitly and document them rather than hiding the logic in a query step.
| Measure | How it is defined | Why it is written this way |
|---|---|---|
| Worked value | Billable activity quantity multiplied by the rate on the entry itself | Uses the historical rate, so a rate-card change cannot rewrite last year |
| Billed value | Invoiced amount on bill line items, cohorted to the bill date | A late invoice lands in the month it was raised, not the month the work happened |
| Billing realization | Billed value divided by worked value, over the same matter and period | Isolates write-downs at invoicing from anything that happens after the bill goes out |
| Collection realization | Collected value divided by billed value, with payments allocated to the bills they settle | Allocation matters — cash in the month is not the same as a bill being paid |
| Overall realization | Collected value divided by worked value | The number partners actually feel, and the one that survives a compensation debate |
| Matter margin | Collected value less timekeeper cost and matter expenses | Cost comes from a rate table you supply, because Clio holds bill rates, not salaries |
| Attorney utilization | Billable hours divided by the target hours for that role and period | Targets by role, so partners and first-year associates are not judged on one number |
| Aged WIP | Unbilled billable activity bucketed by the age of the entry | Shows work ageing toward a write-down while there is still time to invoice it |
| AR aging | Outstanding bill balance bucketed by invoice age | Held at bill level, so a partial payment does not reset the age of the remainder |
| Origination vs responsibility | The same revenue attributed both to the originating and the responsible attorney | Compensation conversations need both attributions visible side by side, not blended |
Matter margin is usually the measure that changes a conversation, and it is the one Clio cannot answer alone. Clio knows what a timekeeper bills; it does not know what a timekeeper costs. Supply salary and benefit costs as a small rate table and a matter that looked healthy at 92% realization can turn out to have been carried by a partner working at associate rates. The modelling discipline underneath — conformed dimensions, one date table, measures instead of calculated columns — is the same craft described on our Power BI data modeling and DAX page.
Clio ships a solid standard report library, and for day-to-day billing and productivity questions it is the fastest answer in the building. It is built to report on Clio, against Clio's shape of the data and Clio's definitions. The questions firms bring us are almost always the ones that cross a boundary — into payroll, into the general ledger, or across several years of renamed practice groups.
| What you are trying to do | Reporting inside Clio | Custom Power BI model |
|---|---|---|
| Standard billing and productivity reports | Its core strength — already built, no engineering needed | Possible, but not the reason to build a model |
| Realization defined your way | Fixed to the definitions the report author chose | Each definition an explicit, documented measure you can change |
| Matter margin including salary cost | Salary and benefit cost does not live in Clio | Cost rates joined to activities and costed matter by matter |
| Multi-year trend across renamed practice groups | Constrained by the current configuration | Slowly changing dimension keeps history comparable |
| Clio joined to the accounting ledger | The accounting sync exists for bookkeeping, not analysis | Ledger modelled as a second fact alongside matters and bills |
| Intake joined to matter outcomes | Clio Grow is a separate product with separate reporting | Both extracted and modelled into one lead-to-collected funnel |
| Where the logic lives | Inside the vendor's reporting layer | In a model file in your own tenant, which you own outright |
The practical answer is usually both. Keep Clio's reports for running the week, and build the model for the numbers that decide compensation, pricing and which practice groups to invest in. If what you want is the firm-wide metric set rather than the Clio plumbing, start with Power BI dashboards for law firms instead — that page covers matter profitability, realization and WIP at an industry level, whichever system a firm bills from, while this one is deliberately the technical half about extracting and modelling Clio specifically.
The model is published to your Power BI workspace and refreshed on a schedule, following Microsoft's documented data refresh guidance (opens in new tab). For firms with several years of time entries and bills, we normally configure incremental refresh (opens in new tab) so only a recent window is re-pulled each cycle instead of the entire history every morning — which also keeps the extract comfortably inside Clio's rate limit.
One API-specific trap is worth naming. Paging a REST source means constructing request URLs in code, and the Power BI service refuses to refresh a query whose data source it cannot determine in advance. The fix is to keep the base address constant and vary only the relative path and query parameters. Attorney-level visibility is then handled with row-level security (opens in new tab) driven from a mapping table of users to matters and practice groups, so onboarding an associate is a data change rather than a development task. Our guide to setting up row-level security covers the configuration in detail. Where trust or IOLTA balances are in scope we treat them as read-only reporting only — the dashboard never initiates or alters a transaction.
Prepaid Flex hours that never expire: Starter 20 hours at $125/hr ($2,500), Growth 40 hours at $115/hr ($4,600), Power 80 hours at $100/hr ($8,000), with hourly work from $100/hour on the largest block. A first build covering matters, time entries, bills, payments and attorney utilization from a single Clio instance usually fits a Starter block. Full matter-margin reporting — salary cost rates, the accounting ledger join, Clio Grow intake alongside outcomes — typically needs Growth, because agreeing the cost rules takes discussion as well as development.
Most tasks ship within 3–5 business days of scope approval. You get a scope and hours estimate before anything starts, and hours deduct only for work you approve. Our guide to Power BI dashboard development cost covers what moves the number, and how prepaid Flex hours work explains the model in full.
Law firms running Clio Manage with enough history to trend and no in-house data engineer — typically the point where someone exports to Excel every month-end and nobody quite trusts the result. Managing partners, firm administrators and legal finance leads are the people who usually get in touch, often after a compensation review where two reports disagreed.
Firms of roughly five to a hundred timekeepers are the sweet spot: big enough that partner-level reporting is a real monthly job, small enough that a dedicated analyst is hard to justify. For utilization-driven practices outside law, see Power BI for professional services; if your firm's accounting sits in QuickBooks or Xero, our QuickBooks and Xero dashboards cover the ledger side of matter margin. Contact is form-only — send your request and we'll reply with a scope estimate.
business days, typical
hours, never expire
own everything
A first Clio build usually fits inside one Flex block, and hours deduct only for work you approve. See Flex pricing →
How it works
Your firm registers a read-only application in a Clio developer account; we confirm your region, work out which custom fields carry meaning, agree the realization and utilization definitions, and reply with a scope and hours estimate before any work begins.
A senior US-based engineer pages the history with the fields named explicitly, conforms matters, contacts, activities, bills and payments into a star schema with a date table, and writes the DAX for realization, margin, utilization, WIP and AR — validating totals against your own Clio reports.
Published to your workspace with scheduled or incremental refresh, row-level security so each attorney or practice group sees only its slice, and documentation you keep. We maintain it from your banked hours.
Representative perspective
Once salary cost sat next to collected value per matter, two practice groups we'd assumed were carrying the firm turned out to be roughly break-even.Managing partner, mid-size litigation firm
Representative perspective
Our own extract worked in Desktop and died on the first scheduled refresh. Getting the authentication, the field selection and the paging done properly was most of the value.Firm administrator, multi-office practice
Tell us how your firm defines realization, whether salary cost rates are available, and the reporting your partners actually ask for. We'll confirm the access route, scope the task, and tell you the hours before anything starts — no project minimums, no obligation.
FAQ
No. Clio does not appear in Microsoft's published list of Power BI and Power Query connectors, so there is no "Get Data → Clio" option to click. The supported route is the Clio Manage API v4 over OAuth 2.0, extracted into a semantic model you own. Firms already replicating Clio into a database can be modelled from that copy instead.
Use them for day-to-day billing and productivity checks. A separate model earns its place when you need realization defined the way your partners define it, several years of comparable trend across renamed practice groups, or Clio joined to payroll and the accounting ledger so matter margin reflects cost rather than billed value.
From time and expense activities, bills and payments, costed against a timekeeper rate table your firm supplies. Clio holds the bill rate rather than what a timekeeper costs the firm, so margin needs that second input. We write worked, billed, collected and cost as explicit DAX measures instead of burying the logic in a query step.
Yes. Row-level security scopes the report so an attorney sees their own matters, a practice-group head sees the group, and the managing partner and firm administrator see everything. It is driven from a mapping table of users to matters or practice groups, so onboarding an attorney is a data change rather than a rebuild.
No. We are an independent US-based Power BI consultancy with no Clio partnership to claim. We build using documented, supported API access under an application your firm registers and owns, and everything we produce is published into your own Power BI workspace and belongs to you if we never speak again.
For the firm-wide metric set rather than the source-system plumbing, Power BI dashboards for law firms is the page to read next. Law firms share their underlying economics with other time-and-billing businesses, so professional services dashboards goes deeper on utilization and realization, and accounting firm dashboards covers the same realization problem from a CPA practice's angle. The ledger join behind matter margin is covered on our QuickBooks and Xero pages, project-based firms billing from a PSA should look at the Deltek Vantagepoint Power BI dashboard build, and the craft underneath is described in data modeling and DAX and dashboard development. Every task is scoped before work begins from your prepaid block of senior-led hours — no project minimums, no change-order surprises, and hours are deducted only for work you approve.
Book a free demo
Tell us the task. We scope it, you approve, and a senior consultant delivers — typically in 3–5 business days. Prepaid hours that never expire.
The fastest way to reach us is the form — tell us the task and we'll reply within one business day.