M&A Advisory Deal Management Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the data model get scoped as accounts and opportunities so often?

Because that is what the person writing the requirements has seen before, and because the first demonstration always looks fine. A pipeline of mandates, each with a stage and a value and an owner, rendered as a board. Everyone nods. It resembles the Monday meeting.

The break happens about six weeks in, when someone tries to enter a real quarter. Company X is the client on the healthcare services sale. Company X is also on the buyer list for two industrials mandates. Company X is a portfolio company of a sponsor your coverage team has called on for years. The corporate development head at Company X moves to a competitor in March and takes the relationship with him. In an accounts and opportunities structure, you get one record with a stage field, and the four true statements about that company cannot coexist.

The consequences show up as behaviour rather than error messages. Bankers stop entering buyer lists because the system cannot hold the roles, associates rebuild client status reports in slides every week, and the weighted pipeline becomes a number the managing partner cannot use for a hiring decision. Adoption in advisory firms is famously poor for this reason, and it is almost never a training problem.

The fix is to model participation explicitly and to test it before you sign. A counterparty participates in a mandate in a role, with a status specific to that role, over a period. A person carries a history of employers, so relationship history follows the human rather than the logo. Coverage is a firm level attribute, not a private contact list. Get the developer to draw that on a whiteboard using your own live quarter, including the person who changed jobs mid process. If they cannot draw it, no amount of interface work will rescue the build.

What goes wrong when you migrate years of contacts out of individual mailboxes?

This is the work item most consistently underpriced in advisory projects, and it is not a technical problem. It is a judgement problem repeated tens of thousands of times.

The source data is four things at once: exported contact lists from individual mailboxes, an abandoned system somebody configured years ago, spreadsheets of buyer lists from past mandates, and signatures buried in email. The same person appears six times with three employers, two spellings and a mobile number that changed, and two bankers each believe they own the relationship.

The failure mode is importing everything, deduplicating with a rule, and declaring victory. What you get is a database where the merged record has the wrong current employer, the wrong owner and a title from 2017. Bankers open it once, find their own contact wrong, and never open it again. In a business where the contact graph is the product, one bad first impression costs you the year.

The fix is to migrate narrow and deep rather than wide and shallow. Take the top two hundred relationships per banker, verify them with the banker, and load those. Load past buyer lists as historical mandate participation records rather than as contacts, so the outreach history survives without polluting the live contact set. Everything else stays in an archive that is searchable but clearly labelled as unverified, and it earns promotion when someone touches it. Deduplication should propose merges to a human rather than executing them, with the loser record retained so a wrong merge is reversible.

Why do the email and calendar integrations break after launch?

Passive capture is the only reason bankers use these systems, since a managing director will not log a call and no design should assume otherwise. It is also the part most likely to be quietly broken three months after go live.

The technical causes are mundane. Authorisation tokens expire when someone changes a password or the firm rotates credentials, and the reconnection prompt lands in a notification nobody reads. A mailbox migration or a change to application permissions revokes access for a subset of users. Each failure is silent, and the symptom is a coverage answer that is subtly wrong: the system says the firm last spoke to an acquirer eight months ago when a partner had lunch with them last week.

There is a second failure that is not technical. Capture gets switched off, informally, because someone was surprised by what was collected. That is a trust failure, and it is permanent.

The fix has two halves. On the engineering side, monitor connection health per user, alert an administrator when a mailbox stops delivering, and show a last synchronised timestamp on the coverage screen so nobody quotes stale data with confidence. On the human side, decide and publish exactly what is captured before the first connection is made. State plainly whether message content is read or only metadata such as sender, recipient, date and subject. Tell staff in writing, and check the position with counsel if you have people in jurisdictions with strict workplace monitoring rules. Firms that surprise their bankers on this lose the capability entirely, and rebuilding trust costs more than the integration did.

What happens when conflicts checks and information barriers are not covered?

Both get deferred to phase two in most scopes, and information barriers in particular cannot be added later without touching every query in the system. Retrofitting them is close to a rebuild.

The visible failure is the one everyone fears: a restricted mandate's details reachable by someone who should not see them, usually through a report, a search result or an export rather than through the screen that was carefully hidden. Hiding an interface while the underlying data remains queryable is not a barrier, and an auditor or a client will find the gap faster than you expect.

The quieter failure is the opposite problem. Barriers implemented crudely hide the existence of a relationship, so a banker approaches a company cold while a colleague on the other side of the wall covers it properly. That is the coverage gap the system was bought to prevent, reintroduced by the control.

Conflicts fail differently. The check happens verbally at mandate acceptance, someone remembers to consider affiliates and someone else does not, and there is no record afterwards. When the question comes back a year later, the firm has an assertion rather than evidence.

The fix is to separate the existence of a relationship from its detail, and to enforce it in the data access layer with logging. A banker can see the firm has coverage of an acquirer and who to ask, without seeing a restricted mandate's contents. Conflicts checks run against counterparties, their affiliates and the deal team's prior involvement, and produce a stored record of the check itself rather than a verbal all clear. If any part of your group is registered, the specific obligations are a matter for counsel, but the engineering requirement is identical either way: evidence the control, do not remember it.

Should you build custom or configure what you already own?

A two or three deal maker boutique doing a handful of transactions a year should not build this. Affinity and 4Degrees give you relationship intelligence for a fraction of a build and require almost no adoption effort, and the money is better spent on origination. DealCloud is the right answer for a firm that needs broad coverage quickly, has budget for a proper implementation and a person to own configuration, and can adopt industry standard processes rather than adapt the tool. Midaxo suits corporate development process management more than sell side advisory. None of these is a weak product, and evaluating them properly is a cheaper first step than any build.

There is also a common case where the software is not the problem. Firms buy a capable platform, never appoint an owner for configuration, and conclude two years later that the tool failed. If nobody in your firm can name the person responsible for the fee fields and the mandate stages, hire or assign that person and give the incumbent platform six months before you commission anything.

Build when the constraints are structural. Fee arrangements complex enough that expected fees cannot be calculated by any system you own. Information barriers that must be enforced technically between teams. A relationship model that genuinely does not fit accounts and opportunities because you cover both sponsors and corporates. Compensation that depends on credit allocation currently argued rather than recorded. Or the plainest signal of all: you have adopted a platform and your bankers still keep the real buyer list in Excel.

How do hidden costs get into the quote?

Six items account for most of the overrun, and four of them look like configuration in a proposal.

• Contact migration and deduplication. Verification with each banker is calendar time you cannot compress, and it is usually priced as an import script.
• Information barriers. They touch every query, every report and every export. Scoped late, they are a rewrite rather than a feature.
• Fee structure encoding. Retainers credited against success, stepped scales, minimum fees, equity components, tails and co adviser splits are arithmetic that lives in engagement letters. Reading and encoding your live mandates is legal and finance time, not developer time.
• Sector team differences. A sponsors coverage team and a sell side execution team want different screens. Two genuinely different processes is close to two builds of that layer.
• Market data enrichment. Joining company and ownership data sounds like a switch and is a licence, a mapping exercise and an ongoing reconciliation.
• Document management. Holding engagement letters and deal files properly, with permissions that respect the barriers, is a subsystem. Pointing at an existing drive is a legitimate and much cheaper choice.

What keeps cost down is a first release limited to live mandates, buyer lists and fee pipeline, with compensation deferred until people trust the data.

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

Nobody types anything they would not have typed anyway. Coverage comes from passive capture, contacts come from signatures, and the only inputs asked of a banker are judgement calls such as deal stage or a rejection reason, requested where they already work rather than in a system they open twice a month.

The client status report generates from the same data the buyer list lives in. That single output is what converts associates from reluctant users into daily users, because it removes work they currently do by hand every week.

Fee structures are encoded for live mandates before the first pipeline meeting uses the system. A weighted pipeline built on stage percentages that mean different things to different bankers is not a forecast, and one bad number in front of the partners will cost you the room.

Credit splits attach to the mandate at signing, before anyone has an incentive to argue, which removes more political heat from a partnership than firms expect.

Ownership is settled in writing before kickoff: the repository, the cloud accounts and the full contact and mandate history. At Digital Heroes the client owns everything from the first commit. Run a complete export during the build rather than after it, so you have proven the exit path while you still have the developer's attention.