A ledger merge looks like a data exercise. Extract from one system, load into another, check the totals.
In practice the data is the part that behaves. What goes wrong is the coordination, and it goes wrong in the same three places almost every time.
All three below happened in the last month. All three are anonymised.
First, why the clock matters
Steadfast slots are booked ahead, with roughly six weeks’ lead time. The slot is held exclusively for you, and if it lapses there is a cancellation fee and a rebooking that puts you months out.
That single fact is what turns ordinary delays into expensive ones. A two-day hold-up in a project with no deadline is nothing. The same two days against a booked slot can cost you the slot.
Realistically the whole thing runs 10 to 12 weeks from first conversation to go-live. Steadfast quote six weeks from booking, and that number is accurate for their part. The queue ahead of it, the forms, and the validation cycles all sit on top. Most of the elapsed time is vendor time rather than anyone’s actual work, which is precisely why it needs chasing.
1. The form goes to the wrong signatory
A merge request needed approval from the source brokerage. Everyone involved assumed that meant the acquiring brokerage, because the acquirer is the one driving the project, paying for it and asking the questions.
It did not. It meant the brokerage the book was leaving.
Two days and several emails went into working out who actually had to sign, against a deadline where missing it meant losing the slot.
Nobody did anything unreasonable here. The assumption is a perfectly sensible one. It is just wrong, and it is wrong quietly, because a form sitting unsigned looks exactly like a form that is progressing.
How to avoid it: before anything else, write down every form in the sequence and, next to each one, the name of the human who signs it. Not the company. The person. Merge or new AR forms need both the source and the destination brokerage. The Sunrise costing request goes to Ebix. Insurer connections are lodged separately. Each has its own signatory and its own lead time, and the one you have not identified is the one that will hold you up.
2. Data that validates is not the same as data that is right
This is the one that costs the most, because it looks like success.
On one file, the import passed validation. Underneath that:
- Nearly two thousand rows carried references in a format the target system would not accept
- Instalments came through as false on every single row, while several hundred of those policies had premium funding sitting against them
- The industry codes did not match between source and target
Every one of those passes a surface check. The file loads. The row count reconciles. And the ledger is wrong.
The instalments one is the clearest example of why a validation pass means very little. A field set to false on every row is internally consistent, which is all a validator is really checking. It takes somebody who knows that a policy with premium funding cannot have instalments set to false to notice that the file is describing something impossible.
How to avoid it: validate the shape, then check the meaning separately. Pick the fields where being wrong has consequences, premium funding, instalments, references, industry codes, and check those against what you know to be true rather than against the schema. Expect to iterate with the migrations consultant more than once. A file that passes first time is usually a file nobody has looked at properly.
3. Mapping errors surface at renewal, not at go-live
On one merge, clients landed against the wrong authorised representative.
Nothing broke. Go-live was clean. Everybody logged in, the policies were there, the numbers looked right.
It surfaced months later, when the ledger would not reconcile.
This is the failure mode that makes ledger merges different from most IT projects. The usual rule is that if it works on day one, you are fine. Here, mapping errors are invisible on day one by definition, because a policy attached to the wrong AR still displays, still renews and still pays. It is only when money has to be attributed that anything looks wrong, and by then you have months of transactions sitting on top of the mistake.
Mapping covers insurers, classes of risk, account managers and ARs. The AR mapping is the one that hurts, because it decides who the revenue belongs to.
How to avoid it: treat the mapping table as the most important artefact in the project, not an administrative step before the real work. Have somebody from the broking side sign it off, not just IT, because IT cannot tell you that this client should sit with that AR. And sample it after go-live rather than waiting for the ledger to tell you. Pulling twenty clients at random and checking who they sit against takes an afternoon in week one. Finding out at renewal takes considerably longer.
The thread running through all three
None of these are technical failures. Each one is a gap between parties.
Steadfast assumes the broker is chasing Ebix. Ebix assumes Steadfast has it in hand. The brokerage assumes both of them are talking to each other, because they are both professionals working on the same project.
Every one of those assumptions is reasonable. Together they mean nobody is chasing anybody, and the first anyone knows about it is a deadline.
Somebody has to own the seam. Not the data, not the configuration, the seam between the three organisations. On the projects that run smoothly, that role exists and has a name attached. On the ones that do not, everybody could tell you afterwards exactly whose job they thought it was.
A short checklist
If you are heading into a merge:
- Name the signatory for every form, including the ones at the source brokerage
- Book the slot early and understand what lapsing costs you
- Separate validation from verification. Passing is not the same as correct
- Check the fields where being wrong has consequences, by hand, against reality
- Get the mapping table signed off by broking, not IT
- Sample the ledger in week one, do not wait for renewal
- Decide who chases the vendors, and tell the other parties who that is