The Clio NetDocuments Integration: Why I Don’t Recommend Turning It On

I was sitting in a bar in Chicago during an ABA Tech show when Clio and NetDocuments decided to build an integration together. At the time, it was a big deal — Clio was the first practice management software to connect to NetDocuments at all, and everybody in the room thought the Clio NetDocuments integration was going to solve a real problem.

Let me get one thing out of the way first: I like Clio. I’m at ClioCon every year and have a good time, and Clio does a lot of things well. But the native Clio NetDocuments integration is not one of them, and after enough implementations, I’ve stopped recommending that firms turn it on. Like the NetDocuments Cosmolex integration, this one creates more cleanup than it saves.

Here’s exactly why.

What Should Happen, and What Actually Happens

Here’s a matter in Clio. Matter ID is 16-001, and it’s a divorce.

Open Edit Matter, and you can see the pieces that matter: the client is Lindsay Bluth, the matter number is 16-001, the matter description is “Divorce,” and the client ID is BLULIN.

That’s clean data. It’s the data you’d want in your document management system. So when I turn on the integration, this is what I expect to see in my NetDocuments Client and Matter tables:

Instead, this is what I get:

Not the same thing at all.

Five Reasons I Don’t Recommend the Clio NetDocuments Integration

Reason 1: The Client ID Is a Database Number No Human Knows

Clio doesn’t send BLULIN. It sends an internal database number — a long string that exists nowhere in your firm’s filing conventions, on nobody’s file label, and in nobody’s head. Lindsay Bluth does land correctly in the client description, so the name is there. The ID your staff actually uses is not.

Reason 2: The Matter Key Isn’t Your Matter Number Either

Same problem one level down. The matter key in NetDocuments is another database number, not 16-001. Clio does put the matter number into the matter description field, which is why people tell me searching still works — and it does, you can find 16-001. But that means your matter description field is now holding a matter number, and the actual description, “Divorce,” never comes over unless somebody types it in by hand at creation time.

Reason 3: The Type of Law Field Comes Over Blank

Clio knows this is a family law matter. It doesn’t tell NetDocuments.

Reason 4: Nothing That Already Exists Gets Linked

With most software, you turn the link on and everything connects. Not here. Turning on the integration links exactly nothing. Every existing matter has to be linked by hand, one at a time.

If you’re brand new to Clio with no clients and no matters yet, fine — you’ll never notice. If you have 500 clients and matters already in Clio, do the math: call it a minute per matter if nothing goes wrong, and that’s more than eight hours of somebody clicking through matters. That also assumes the client already exists on the NetDocuments side.

Reason 5: The Matter View Inside Clio Is the Worst Way to Look at NetDocuments

Once a matter is linked, you get a NetDocuments view embedded in the Clio Documents tab.

I don’t want to look at a matter that way. Nobody does. If I want to work in NetDocuments, I’ll go to the NetDocuments tab, where I have my Workspace, Filters, and search.

Why This Happens: Clio Doesn’t Really Have Clients

It’s worth understanding the root cause, because it explains everything above.

NetDocuments will not let you create a client without a Client ID. It will not let you create a matter without a Matter ID. Those fields are required, full stop.

Clio doesn’t work that way. Clio doesn’t really have a traditional client at all — it has contacts, and on a contact there’s a checkbox that marks that contact as a client. You can have a “client” in Clio with no client ID whatsoever, and Clio will never stop you. Matters are the same. The data is optional on the Clio side and mandatory on the NetDocuments side, and that mismatch is exactly what you’re looking at in the tables above.

This is also why Clio-to-NetDocuments document migrations are the projects I dread most. Before anything can move, somebody has to clean up a mountain of Clio data — clients with no IDs, matters with no IDs, contacts that may or may not be clients. Nobody ever has to clean up NetDocuments data going the other direction, because NetDocuments never lets it get dirty in the first place.

And you should get your documents out of Clio. Moral of the story: Clio is great practice management software. Don’t use it as your DMS.

But Can’t I Just Start Clean Going Forward?

This is the objection I get every time, and I understand it. The firm says: leave the old matters alone, turn on the integration, and everything new will be consistent from here.

The problem is that “consistent” is doing a lot of work in that sentence. Every new matter still arrives with the database-number client ID and matter key. So now you have two conventions living in the same Cabinet — the clients your staff created properly, and the clients Clio created.

Go to a client to see all their matters, and you find them split across two client records. That’s not a going-forward fix. That’s a permanent split in your filing structure.

The One Exception: When I Will Turn It On

There is a scenario where I do turn the native integration on, and it comes up often enough to be worth naming. The firm is already running Clio, has never used NetDocuments, and — this is the part that matters — doesn’t really use client IDs or matter IDs in Clio to begin with.

If nobody at that firm has ever typed BLULIN or 16-001, then the database numbers Clio pushes over aren’t replacing anything. There’s no convention to break, no existing filing scheme to contradict, and no old client records to split in two. The integration costs them nothing they were using, so I’ll turn it on and let it create the structure.

That’s the exception. In every other scenario, I keep the two systems separate.

There Is a Third-Party Option That Fixes This

Another company has built its own Clio NetDocuments integration, and it addresses essentially everything on the list above. GDSI’s integration engine pushes the correct client ID and matter ID into NetDocuments, automatically linking all of your existing clients and matters instead of having someone click for eight hours.

• GDSI Clio Integration Engine for NetDocuments – https://gdsi.com/clio-integration-engine-for-netdocuments/

If you want Clio and NetDocuments genuinely connected, I’d look there rather than the native link.

If You’re Still Shopping for Either One

This is the part worth planning for before you buy. If you don’t have Clio yet, or you don’t have NetDocuments yet, and you’re evaluating one to sit alongside the other, spend real time on your numbering scheme first. Decide what a client ID looks like, decide what a matter number looks like, and make both programs agree from day one. Cleaning that up after two years of filing is far more expensive than getting it right at the start.

The Bottom Line

The native Clio NetDocuments integration doesn’t send over the two pieces of data that matter most — your client ID and your matter number — it leaves Type of Law blank, and it links to nothing you already have. If your firm already uses real client IDs and matter numbers, keeping the two systems separate and linking matters deliberately produces a cleaner Cabinet than turning the integration on and living with database numbers forever. If your firm has never used IDs, turn them on; you’re not losing anything. And if you want them properly connected, buy the GDSI integration.

Running Clio and NetDocuments and not sure how to get your client IDs and matter numbers lined up between them? We do this for firms regularly and can usually tell you what your cleanup looks like in a single call.

Schedule a free consultation at go.oncehub.com/optconsult.

Optiable has guided over 550 law firms through NetDocuments implementations since 2010, specializing in firms with 10 to 150 users.