Entity Management Software Problems: The 6 That Cost Real Money, and How to Avoid Them

Why does the design collapse into a companies table with optional fields?

The first scope decision is usually made in an hour and paid for over three years. Somebody sketches an entity table, adds columns for registered office, incorporation date and jurisdiction, then adds a directors table with a name and a role. It looks correct because most of your entities are companies and most of your questions are about today.

Then the rest of the structure arrives. A Jersey trust has trustees, a settlor, beneficiaries and often a protector, and no directors at all. A Delaware LLC has membership interests and a manager, not shares and a board. A Luxembourg SARL has a notarised share register. A general partnership has partners with capital accounts and profit shares that are different numbers. A Dutch stichting has a council. None of these are companies with a type field set differently, and the moment you treat them that way the workarounds begin, usually as a free text notes column that becomes the real register.

The fix is to define entity types that own their own registers and obligations, joined by a general interest relationship that can express shares, membership interests, partnership interests or beneficial interests. That is what lets one ownership chart span the whole group honestly. Do it in week two of design, because retrofitting it once 400 entities are loaded is a migration project rather than a change.

What goes wrong when you migrate minute books and historic share capital?

Entity migration is not a data task. It is a reading task. The current officer list can often be pulled from a public registry in an afternoon. The share capital history cannot, because it lives in allotment resolutions, transfer forms, buyback documents and, for the entities you acquired in a deal, a set of physical binders somebody has to open.

Two failures repeat. The first is budgeting migration as developer time when the work is paralegal time, which means the project runs out of money at exactly the point where the register becomes useful. The second is loading what is easy and leaving the system silently implying that the rest is complete. A register showing three share transactions for an entity that has had eleven is more dangerous than an empty one, because somebody will rely on it.

Two things fix this. Tranche the load: active entities in your main jurisdictions first, dormant entities later, and historic share capital built over months rather than at go live. And give every entity an explicit completeness state, so a user sees that the pre 2019 history for this company has not yet been captured instead of assuming the gap is a fact. That single field is the difference between a partial register you can trust and one you cannot.

Why do registry lookups, signature and document store links break after launch?

The integrations in this category look easy on a diagram and are not. Public registry lookups return data your system did not ask for and stop returning fields it relied on. Registered agent portals frequently have no interface at all, so somebody builds a scraper, and the scraper breaks on a layout change nobody announced. Signature envelopes go out and the completion status never comes back, so a resolution shows as pending forever. And the document store, usually SharePoint or a network drive, drifts because two permission models now govern the same files.

The failure is nearly always the same shape. The integration was built as a sync with no reconciliation, so when it drifts, nothing tells you. Six months later a filing goes out against an address the registry updated in March.

Fix it three ways. Treat the registry number as an external identifier and never as your primary key, so a re-registration does not orphan the record. Run every external feed as a comparison that produces a differences report a human clears, rather than an overwrite. And decide, in writing, that the entity system is the master for register data and the document store is a mirror, because two masters means two answers to the same question and a very bad afternoon during diligence.

What happens when the filing calendar and beneficial ownership are not covered?

These are the two gaps that turn a records problem into a legal one. A UK company files a confirmation statement annually. A Delaware corporation has an annual report and franchise tax due on 1 March. Registered agent renewals, local director requirements and beneficial ownership register updates all run on their own cycles with their own consequences, and persistent failure to file in the UK leads toward the company being struck off the register.

When the calendar is not in the system it is in a person, and people take leave. When beneficial ownership is not in the system it is a manual multiplication up the ownership chain, done in a spreadsheet, for a structure that changed twice since the last calculation.

Generate obligations rather than typing them. Entity type plus jurisdiction produces the right calendar automatically, so adding a company in a country you already operate in creates the correct deadlines with no human step. Each obligation carries an owner, a lead time and an escalation, and completion requires the filed document to be attached so that completed means evidenced rather than ticked. For ownership, compute the chain, apply the threshold for the jurisdiction, show the calculation, and flag trusts and nominee arrangements for human judgement instead of computing through them. That restraint is not a limitation. It is the boundary between software and legal advice.

Should you build custom or configure what you already own?

A real answer, not a hedge. If you hold under about 40 entities in one or two familiar jurisdictions and every one of them is a conventional company, do not build. EntityKeeper is inexpensive and adequate at that scale. If your group is North American, Athennian is a well built modern product with genuine depth in the corporate law it serves, and effective dating is handled properly. Diligent Entities has broad enterprise coverage and is the safer choice where you need the register and little else. If your registered agent is CSC and the relationship is good, keeping records there is defensible, with the obvious caveat that it deepens a dependency on one provider.

Build when two or more of these are true. You hold more than roughly 150 entities. Your structure spans three or more legal systems, particularly mixing common law and civil law. You hold trusts, partnerships or foundations that no share capital model fits. You are a law firm or trust company administering entities for clients and need multi tenant separation with client portals under your own brand. Or you have already had a filing miss, a restoration, or a deal delayed because the structure could not be evidenced on demand.

How do hidden costs get into the quote?

Four ways, and all of them are visible if you ask.

• Jurisdictions priced as one line. A quote that says multi jurisdiction support has not counted the work. Each legal system brings entity types, registers and filing rules that are genuinely different, and the third one costs as much as the first two.
• Migration excluded or assumed. If the proposal does not name who reads the minute books and how many hours that is, the number will arrive later as a change request when you are already committed.
• Multi tenancy discovered late. Client separation for a trust company has to be enforced at the data layer. Adding it after launch touches every query in the system.
• As at date arriving in month four. If effective dating was not in the original scope, the correct fix is a rebuild of the register model, and it will be quoted as one.

The honest bands from Digital Heroes delivery experience are $60,000 to $130,000 over 12 to 16 weeks for a first release covering the register, effective dated officers and ownership and the filing calendar, and $150,000 to $400,000 over 6 to 11 months for a full platform. What keeps you at the lower end is loading your top jurisdictions and active entities only, and treating dormant entities as a later tranche.

What separates a build that works from one that fails here?

Ask how they would store a director appointment. If the answer is a field on the entity, stop. The correct answer is an effective dated relationship with a start, an optional end, a role and an evidencing document, and a developer who has done this raises as at date queries before you do.

Ask how they would model a Jersey trust and a Delaware LLC in the same system as an English limited company. Someone who has built this describes distinct entity types with their own registers. Someone who says they will add a type column is about to build a system that cannot hold half your structure.

Ask what they will refuse to automate. A developer who says beneficial ownership through a trust gets flagged for a lawyer rather than calculated understands where software should stop, and that judgement is worth more than any feature on the list.

Then settle ownership before kickoff, in writing: the repository, the cloud accounts and the right to bring in another firm. At Digital Heroes the client owns the code from the first commit. For entity work, agree the structured export format at the same time, because a statutory register you cannot extract is a register you do not really control.