Conflicts and Independence Clearance Software: How Do You Clear New Business in Hours Instead of Reading 400 False Positives?

Why clearance turns into a queue nobody can get through

A partner wants to open a matter on Friday for a client who needs an answer by Monday. Intake runs a search. It returns 380 potential hits: every entity whose name contains a common word, every former client whose matter closed in 2009, three companies that share a registered agent, and one that genuinely matters, a subsidiary of the proposed adverse party that the firm represents in an unrelated regulatory matter out of another office.

A senior lawyer now has to read all 380 to find the one. On a Friday. With a partner asking every two hours. That is the actual conflicts problem at most firms, and it is not a search problem. It is a precision problem. Everyone can find hits. Nobody can rank them.

The consequences of getting it wrong sit at both ends. Miss a real conflict and the firm can be disqualified from the matter, lose the fees, and face a claim. Over report and the practice grinds, partners start describing intake as an obstacle, and the informal workarounds begin, which is where the genuinely dangerous failures come from. For an audit firm the stakes shift shape but not size: an independence breach caused by a partner's personal holding, a prohibited non audit service or a missed cooling off period is a regulatory event, not a commercial one.

The professional rules are public and clear enough. Current client conflicts, former client duties, imputation across the firm and duties to prospective clients sit in the ABA Model Rules at 1.7, 1.9, 1.10 and 1.18 and their state equivalents. For audit, independence rules from the SEC and PCAOB, the audit committee pre approval requirements introduced by Sarbanes Oxley, and the European audit regulation's restrictions on non audit services all define what must be checked. What none of them do is tell you how to reconcile a party name typed by a secretary against a global corporate family tree at 6pm on a Friday.

Problem 1: party names are typed by humans and matched by machines

Everything downstream depends on knowing what entity you are actually talking about. Intake receives a name, sometimes a trading name, sometimes a misspelling, sometimes a group name where the counterparty is a subsidiary two levels down in another jurisdiction. Your own client database has the same entity recorded four ways because four different secretaries opened matters over fifteen years.

A build fixes this with an entity resolution layer rather than better string matching. Names are normalized, aliases are stored, and parties are linked to external references such as company registry numbers and legal entity identifiers where they exist, then joined to corporate family data so a hit against a subsidiary surfaces the parent and the siblings. Every party gets resolved once and reused, so the fourth matter for the same client does not re-enter the same ambiguity. This is unglamorous data engineering and it is where the accuracy actually comes from. A rule chain running over unresolved names cannot be made precise no matter how clever the rules are.

Problem 2: scoring, not searching, is what saves the reviewer

The reason reviewers drown is that most systems return matches rather than judgments. What a reviewer needs is a ranked list with reasons: this hit is high risk because the party is a current client of the firm in an active matter, in the same industry, with a lawyer in the same office. This hit is low risk because the name matched a dissolved entity with no matter activity in eleven years.

A build implements scoring with explicit, explainable factors: relationship type, matter status and recency, adversity of role, corporate proximity, practice and office overlap, and fee significance. Reviewers work in confidence bands, with everything above a threshold read in full and low band hits sampled rather than exhaustively reviewed, under a policy the general counsel signs off on. Two design rules matter. Every score must be explainable in plain language, because a reviewer will not trust a number, and the scoring model must be versioned, because in two years someone will ask what the system knew and how it ranked it on the day you cleared the matter.

Machine assistance belongs here and nowhere near the decision. Classifying party roles from a matter description, spotting that two spellings are the same person, extracting parties from an engagement letter or a term sheet: all sensible. Deciding whether a conflict exists: never. The output of the system is a ranked, evidenced queue for a human with authority.

Problem 3: Intapp is strong on process and cannot fix your data or your rules

Intapp Conflicts is the established product in this category and it does the core job properly: structured intake, searching firm records, workflow and approvals. Firms with straightforward practices run it successfully and we would not push anyone off it without a reason.

Where firms hit the edges is specific. First, precision is limited by the data you attach, so if corporate family information is thin or your own party records are unreconciled, you get noise regardless of the product. Second, rule chains that vary by office, jurisdiction, practice line and engagement type, which is normal in a firm with an alliance structure or an audit and advisory mix, quickly exceed what a packaged configuration model wants to express. Third, independence for audit adds obligations the legal conflicts model was not designed around: restricted entity lists ingested from clients and regulators, personal financial interest declarations covering partners and their immediate families, service pre approval workflows and cooling off tracking. Fourth, wall enforcement often stops at recording that a wall exists rather than provisioning and proving it in the systems where documents and time actually live.

That last point is the one that turns into a finding. A wall that exists in a conflicts database but not in iManage or NetDocuments is a policy, not a control.

Problem 4: walls must be provisioned and proven, not declared

When a conflict is cleared subject to screening, someone has to make the screen real: restrict document access in the document management system, restrict the matter in time and billing, exclude screened personnel from distribution lists and matter reporting, and record acknowledgements from every screened individual. Then someone has to prove, possibly years later, that the screen was in force on a particular date and that no screened person accessed anything.

A build treats a wall as an executable object. Declaring it triggers provisioning through the document management and practice management APIs, acknowledgements are collected and tracked, access attempts by screened individuals are logged, and periodic attestations run automatically. The evidence pack is generated, not assembled. Firms that have been through a disqualification motion understand exactly why that distinction is worth paying for.

Problem 5: laterals, and the independence problems that arrive with people

A lateral hire brings a client list you must clear against your own book, and the timing is awkward: you need the analysis before the offer, using information the candidate can lawfully share, which is usually names rather than matter detail. Doing that in a spreadsheet under time pressure, confidentially, is how firms discover a problem after the announcement.

On the audit side the equivalent is personal financial interests. Partners and their immediate families hold investments, and independence depends on those holdings not touching the restricted entity list, which changes as the firm wins and loses engagements. Managing that with an annual declaration form guarantees you are out of date for eleven months of every year. A build ingests restricted entity lists on a schedule, collects holdings declarations with structured identifiers rather than free text, and evaluates continuously so a breach surfaces when the list changes rather than at the next annual cycle. It also tracks non audit service pre approvals and cooling off periods against the same entity data, so the answer to whether a proposed advisory engagement is permitted comes from the system rather than from a partner's recollection.

What this costs and how long it takes

A first release covering structured intake, party resolution with corporate family matching, explainable hit scoring, a configurable rule chain and a reviewer workbench runs $90,000 to $200,000 and ships in 14 to 20 weeks in our delivery experience. A full platform adding ethical wall provisioning into document and practice management, waiver and advance waiver registers with scope and expiry, restricted entity list ingestion, personal holdings declarations, service pre approval workflows and the immutable clearance audit trail runs $250,000 to $600,000 across 9 to 18 months.

What drives price up specifically in professional firms: the number of jurisdictions and regulators, since rule chains multiply rather than add. Whether you have both audit and advisory lines, which effectively means two rule models over one entity graph. Historical data reconciliation across your client and matter records, which is the most commonly underestimated line and the one that determines precision. Corporate family data licensing and integration. And integration count, since a document management system, a practice management or finance system, a customer relationship system and an identity provider are four separate pieces of work.

What keeps it down: one office, one practice line, intake and scoring only, with walls in phase two. Reviewer hours saved show up in the first month.

Build versus buy, and when buying is right

Buy if you are a single office firm under roughly 40 fee earners with one practice area and no audit line. Intapp or a comparable product plus disciplined intake will serve you, and the money is better spent on the discipline than on software. Buy as well if your problem is that you have no structured intake at all, because a product will get you to a baseline faster than a build and you can revisit the question in two years with real data about where it hurts.

Build when two or more of these are true. Reviewers are reading hundreds of hits per matter and clearance has become the bottleneck on revenue. You run audit and advisory lines under one independence regime and the packaged model cannot express your rule chains. You hire laterals regularly and each one is a manual confidential exercise. You have been in a disqualification fight, or an inspection finding, where you could not produce evidence of a wall being in force. Or your firm operates through an alliance or verein structure where imputation rules genuinely differ across member firms.

The tipping point is precision, not features. If your reviewers trust the ranking, clearance takes hours. If they do not, they read everything, and no amount of workflow will save them.

How to choose a developer for conflicts and independence software

Ask how they will resolve a party before matching it. If the answer does not include normalization, alias storage, external identifiers and corporate family linkage, you will get a faster search over the same noisy data and reviewers will be no better off.

Ask how a score gets explained to a reviewer and how it is reproduced two years later. The right answer includes plain language reasons on every hit, versioned scoring models, and a frozen record of what the system knew at the moment of clearance. That record is the thing you will need if the decision is ever challenged.

Ask how a wall gets enforced. If it is a status field, keep looking. You want provisioning calls into your document management and practice management systems, acknowledgement tracking, access logging and generated evidence packs.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the cloud accounts and the right to hire another firm. At Digital Heroes the client owns the code from the first commit. A clearance system holds your firm's institutional memory of every relationship it has ever had, and that belongs to the partnership rather than to a vendor.