Build once, submit many: the case for a matter database

If you ran a software company and three different investors asked for three different versions of your metrics every quarter, you wouldn't rebuild your metrics from scratch each time. You'd maintain a single internal source of truth and render it differently for each audience.

Law firms do the opposite.

Chambers wants one format. Legal 500 wants another. IFLR1000 wants a third. The underlying information — who did what matter, for whom, in what role, with what outcome — is almost identical. But most firms treat each submission as if it starts from a blank page, re-gathering the same facts from the same people, three times a year.

The cost isn't just duplicated effort. It's compounding inconsistency, lost institutional memory, and a BD function that spends its best hours on data entry instead of strategy.

This is not a writing problem. It's a data problem. And the solution is a matter database designed around the one thing law firms actually do with matters most: submit them.

What a matter database is (and isn't)

"Matter database" is a phrase that gets used loosely. For clarity: here we mean a structured, shared, directory-aware store of matter information — captured once at the point of matter close-out, then used repeatedly across Chambers, Legal 500, IFLR1000, pitch documents, credentials decks, and internal reporting.

It is not:

• A practice management system (that tracks time, billing, conflicts)
• A document management system (that stores files)
• A CRM (that tracks clients and business development pipeline)
• A pitch library (that stores pre-written content)

Most firms have the first three. Some have the fourth. Almost none have a matter database in the sense used here.

The distinction matters because each of those other systems was built for a different primary purpose. Bolt-on modules that claim to serve submissions usually inherit the limitations of the system they're bolted onto. A matter database needs to be built around directory fields, because that's where the complexity lives.

The specific fields that matter

What makes a matter database submission-native rather than submission-adjacent? A handful of specific design choices:

Directory-specific field variants. Chambers cares about different dimensions of a matter than Legal 500 or IFLR1000. A submission-native database captures each directory's preferred framing natively, not as an afterthought.

Narrative layers separated from data layers. The facts of a matter (client, value, date, role, outcome) are stable. The narrative around it (how you position it, what you emphasise, how it relates to this year's story arc) evolves. Collapsing these into a single field — as most firms do in Word documents — makes both harder to maintain.

Confidentiality tracking at the field level. Not every fact about every matter can be submitted to every directory. A matter database that knows which fields are public, which are anonymisable, and which are strictly confidential prevents the most common submission mistake: inadvertent disclosure of client-confidential information.

Referee cross-referencing. Matters and referees aren't separate data. Every nominated referee is nominated for a specific matter. A matter database that treats this as a first-class relationship prevents the year-to-year drift where referees get nominated for matters they don't actually remember.

Team composition with role granularity. Partners, associates, trainees — each matter's team composition matters for directory credibility. Firms that capture this at close-out (not reconstruct it in February) get accurate team stats without a manual audit.

The "build once, submit many" principle

The test of a submission-native matter database is simple: can the same underlying matter, captured once, be rendered accurately and compellingly for Chambers, Legal 500, and IFLR1000 without the team re-typing anything?

If the answer is yes, you've solved the duplication problem. If the answer is no, you have three parallel workstreams every February.

This sounds like it should be obvious. It isn't, because most firms' information architectures have evolved accidentally. Matter summaries live in closing documents. Client names live in practice management. Referees live in a BD spreadsheet. Deal values live in billing. Team composition lives in lawyer memory. Pulling these together each February is the entire problem.

A matter database doesn't eliminate the work. It eliminates the duplication. One data capture, multiple outputs.

Coherence: the hidden cost of fragmentation

There's a subtler failure mode that a matter database addresses: coherence.

If your Chambers submission describes a practice as "leading" in one field while your Legal 500 submission positions the same team as "emerging," researchers notice. If your IFLR1000 credentials list a deal that's missing from Chambers, researchers notice that too. If your D&I statistics don't reconcile across three submissions in the same year, researchers definitely notice.

These inconsistencies don't come from dishonesty. They come from different people writing different submissions using different source documents with no cross-check. A matter database with coherence checking — automated flagging of inconsistencies across submissions — removes the cognitive burden of maintaining a consistent story across directories.

This is the kind of problem that can't be solved by hiring more BD managers. It can only be solved by infrastructure that makes inconsistency visible before submission.

Year-on-year intelligence

The most underrated benefit of a matter database is something most firms don't realise they're missing: year-on-year intelligence.

If last year's Chambers submission emphasised your practice's shift into cross-border mandates, this year's submission should build on that narrative, not contradict it. If the researcher you spoke to last year noted concerns about team depth, this year's submission should address that concern explicitly. If a competitor leapfrogged you in a specific ranking, this year's strategy should know why.

Institutional memory of this kind is almost impossible to sustain in documents. Documents get filed, renamed, lost, or simply not read. A matter database with ranking history, submission history, and researcher-note history turns each year's submission into an iteration on the last, not a restart.

Over three cycles, the difference compounds dramatically. Firms with institutional memory climb. Firms without it plateau.

The three questions most firms can't answer quickly

A useful diagnostic. Ask your BD team these three questions and time the response:

• "Which matters did we submit to Chambers last year, and which were ranked?"
• "Which referees have we used in the last three cycles, and what was the cadence?"
• "How did our D&I statistics shift year-on-year, and how did we describe that shift in each submission?"

If any of these takes longer than ten minutes to answer, your infrastructure is the bottleneck. Not your talent, not your matters, not your referees. Your infrastructure.

What to do about it

Three options, in increasing order of ambition:

Option 1: Impose discipline on your existing tools. Create a template that everyone uses, mandate matter close-out documentation, appoint a single owner for directory submissions. This helps. It doesn't scale, and it breaks when key people leave.

Option 2: Extend an existing system. If your firm has a practice management or document management system flexible enough to host structured matter records with directory-aware fields, you can build the database inside it. This works for some firms. It usually requires custom development and ongoing maintenance.

Option 3: Adopt purpose-built software. Specifically designed for the submission use case, with directory fields, coherence checks, referee CRM, and year-on-year intelligence as native features rather than customisations.

SubsIQ is Option 3. It exists because Options 1 and 2 hit ceilings most firms eventually encounter. The self-serve demo is here:

Try the demo →

It's loaded with a fictional mid-size firm, including sample matters, referees, and submissions across Chambers, Legal 500, and IFLR1000. Fifteen minutes will tell you whether the approach fits your firm's reality.

The deeper question — whether your firm is ready to treat directory submission as a year-round operational discipline rather than a February panic — is one no tool can answer for you. But if you're ready to ask it, the infrastructure exists.