It's always about trust
When I work with clients on almost any data management project, a very common theme is one of trust. Or more specifically, a lack of trust in the data that's in the primary system.
This is reflected in the way staff talks about the data, very often saying things like "I don't think the data is being updated frequently (or at all!)" or flat out saying "I don't trust that the data is accurate." And the problem with a lack of trust is that it leads staff to manage data outside of the primary system (see The Cycle of Doom).
I read once long ago that for every act that creates mistrust, multiple acts of trust are required just to regain the trust lost on that single act. In other words, it's not a one-to-one equivalence; you have to have moreacts of trust to balance out any mistrust.
Something similar is at work with your database. Staff can happily use the system for days, weeks, or months (trust!) but if they come across multiple errors (or even one very significant error), all that trust can be lost immediately.
So it's up to us to do all we can, every day, to make sure the data is as trustworthy as we can make it. Not perfect (unattainable), but trustworthy.