Every system in an MSP's stack follows rules. The PSA adds a charge when an agreement says so. The accounting system syncs invoices. The distributor portal renews a license on a schedule. Each rule was written by a sensible person to solve a real problem.
The trouble starts when two of those rules touch the same thing and want different results. Neither is broken. Both report success. And the client ends up with a bill that nobody intended.
Consider an illustration. A client lets 12 employees go. The service desk closes the tickets, and the licenses are removed in the vendor portal, so the vendor now bills for 28 seats. The PSA agreement still says 40, because its quantity is set by an older rule and nobody updated it. The accounting system, doing its job, invoices from the PSA.
Three systems followed three sets of rules. Every one of them is correct by its own logic. Together they overbill the client by 12 seats, month after month, until someone notices.
This is the pattern. Rules are written locally, to solve one team's problem in one system. Outcomes are global, because the client sees one invoice. When rules in different systems overlap, the gap between them belongs to no one.
Because nothing fails. A broken integration throws an error and gets fixed. Two working rules that disagree throw nothing. The PSA says its quantity is right. The vendor portal says its quantity is right. Both are telling the truth about their own data.
The disagreement surfaces somewhere else: as a client who questions an invoice, as margin that thins without an obvious cause, or as a credit issued to keep the peace. By then the original conflict is months old, and tracing it back means reconstructing what each rule did and when.
This is also why the problem grows with the stack. Each new tool and each new rule adds another place where two of them can pull in opposite directions.
This is the question underneath the conflict. Ownership in most MSPs is organized around systems. One person owns the PSA, another owns accounting, another owns purchasing. Each owns the rules in their system.
Nobody owns the outcome that crosses all of them: the client is billed for what was delivered, no more and no less. When that outcome has no owner, every conflict between rules is nobody's problem until it becomes a client's problem.
The fix starts with naming the outcome and giving it a person. Not "keep the PSA clean," which is a system goal, but "billed equals delivered," which is an outcome. The owner of that outcome does not need to control every rule. They need the authority to ask which rule won, and why.
You cannot eliminate overlapping rules in a stack this connected. You can decide, ahead of time, what happens when they collide.
Reconciliation is the layer that sits above the individual systems and looks at the outcome. It does not replace the rules in the PSA, the portal, or the accounting system. It compares what each one produced and shows where they diverge.
Reconcile works this way. It compares vendor invoice data against billing agreements and surfaces discrepancies in both directions: things billed that should not be, and things delivered that are not billed. For an MSP with a connected stack, that comparison is how a conflict between two reasonable rules becomes visible while it is still one month old.
What does it mean when two automations disagree? It means two rules in different systems, each working as designed, produce conflicting results for the same thing, such as a seat count or a charge. Neither system reports an error, so the conflict goes unnoticed until it shows up in an invoice.
Why do rule conflicts cause billing errors in MSPs? Rules are written locally by different teams to solve different problems, while the client sees one combined invoice. Where rules overlap, nothing decides which one wins, so the billing outcome can be wrong even when every system is functioning correctly.
Who should own the billing outcome in an MSP? A named person should own the outcome that crosses systems, such as "billed equals delivered," in addition to whoever owns each system's rules. That owner needs the authority to investigate which rule produced a result and why.
How can MSPs catch conflicts between systems? By inventorying the rules that touch money, naming a source of truth for each kind of data, routing disagreements to a person, and regularly comparing vendor bills, agreements, and client invoices.