A payment to the wrong bank account is how most finance teams find out what a data silo costs. Procurement's vendor portal has the supplier's current IBAN, updated three months ago after a legitimate account change. Accounts Payable's ERP has the IBAN from the original vendor setup, two years old, because nobody told it to update. The payment run reads from the ERP, because that is the system that pays. The money leaves on the old number. Nobody notices until the real vendor calls asking where theirs is.
Nobody in that story would call it a data silo, because both systems sit inside the same company, both feed the same monthly close, and somebody could technically query either one. That is exactly the trap the word sets. A silo is not about distance between systems. It is about which one gets to be right, and in this story nothing ever answered that question. We wrote about the sharper version of this failure, a changed bank account nobody re-verified, in vendor master data and payment fraud.
What a data silo actually is
A data silo is a set of data one system, team, or department controls, which the rest of the organization cannot reliably see or use. The usual picture is a missing wire: two systems that simply never talk to each other. That picture is wrong often enough to matter. Procurement and Accounts Payable in the story above are both plugged into the same ERP, file through the same processes, and probably both appear on the same executive dashboard by Friday. They do not share one place where the supplier's IBAN is decided. Two systems, two truths, and a payment run that trusted the wrong one.
That distinction, between not being connected and not being decided, is the one almost every article about data silos skips straight past.
The fix everyone writes down first
Search for data silos and most of what comes back is the same shape: a vendor names a few business consequences, then lands on the same three-step fix. Break down the walls. Centralize the data, usually in a warehouse or a lake. Connect the systems with an ETL pipeline or an integration platform. As a description of plumbing, that is fine advice. As a description of what removes a silo, it describes what makes one wider.
Run a nightly job from Procurement's portal and the ERP into a shared warehouse, and the warehouse will faithfully receive two IBANs for the same supplier, hours apart, forever. A pipeline has no opinion. It moves bytes from a place that holds them to a second place that now also holds them. The warehouse is not less siloed than the systems it drew from; it is a third copy, sitting downstream, reporting what each source thought last night. We went into why that gap survives even when the pipes run perfectly in why your data warehouse lies.
What actually closes it
Closing a silo means removing the second copy, not building a faster road to it. Procurement and Accounts Payable stop keeping their own IBAN and start reading one supplier record that only one place is allowed to change. There is no disagreement left to reconcile, because there is only one value to begin with.
That takes two things a pipeline does not provide. The first is a gate on every route a change can arrive through, typing, a paste, a file import, an overnight load, an API call, so the record cannot drift back into disagreement through a door nobody was watching. We covered that mechanism on its own in garbage in, garbage out.
The second is a way for other systems to read the current answer live, rather than take a nightly copy that is a fresh silo of its own by morning. The full shape of what that takes is in single source of truth, and the distribution side specifically in what replaces subscriber views.
In Primentra the supplier record lives once, on your own SQL Server. Procurement and Accounts Payable both read it through an integration view or the REST API instead of maintaining their own field, and a change to the IBAN goes through the same business rule and, if you configure it that way, the same approval, no matter which screen or system it came from. The silo does not get connected. It gets closed, because there is nothing left on either side to disagree with.
What this does not fix
It does not decide the IBAN is correct. It only guarantees there is one of them to be wrong about: one record to verify with the bank, instead of two records that have to disagree before anyone notices.
It also does not pick itself. Somebody still has to own the supplier domain and say which team is allowed to change the record, and that decision is organizational, not technical. Skip it and you get a very well-connected argument instead of a resolved one, which is the subject of nobody owns your master data.
Common questions
We already have an ETL job between these two systems. Isn’t that enough?
It is enough to see both values. It is not enough to know which one is right. A nightly load faithfully carries Procurement’s IBAN and Accounts Payable’s IBAN into the same table without ever comparing them, and a payment run still has to pick one. Connection is not the same job as decision.
Our data lake has everything in one place. Isn’t that the fix?
One place to look is not the same as one place that is right. A lake holds every version any source system ever sent it, timestamped, and none of them are edited there. It answers "what did each system say" very well and "which one do I trust" not at all.
Is this the same thing as a single source of truth?
Closely related, from a different angle. A silo is what you have when nobody decided; a single source of truth is what you have once someone did. We wrote about what building one takes in single source of truth: the phrase everyone uses and almost nobody has.
How do you actually break down a data silo?
Pick the domain causing the most disagreement, usually supplier, customer, or product. Give it one place where a person or process is allowed to decide the value, a gate that checks every route data can enter, and a way for other systems to read the current answer instead of taking a nightly copy. That is a master data problem, not an integration project.
Find the record two systems disagree about
Give it one home instead of a faster pipe between the copies. Primentra runs on your own SQL Server, deploys in a day, and costs €7,500 per year flat, with a 60-day trial.