How can I communicate the risks of altering vendor software?

Question

We have a major problem where I work, and it's name is "customization". We have an old (10+ years) vendor software system that our IT and accounting departments previously loved to customize. Somewhere along the line this software started getting very buggy. Then, I was hired after the bulk of the customization.

Nearly every problem I've found with the system is a direct result of customization; everything we change risks breaking business critical financial software. Yet the accounting department keeps suggesting changes (because we always said yes!) and there seems to be little respect for how impactful changes might be.

Some changes cause no problems; forms can be (and are meant to be) customized in the vendor software, we can move around form fields, remove them, ect. But for every harmless customization like that they also suggest changes like stored procedures and triggers to manipulate data in the database for the vendor application.

I recently (barely) got them to stop trying to import customers from one vendor program into another as the information was completely incompatible. My problem with how that was resolved is because I found the system didn't work on the user side; the task was more complicated than they thought so they gave up. Regardless of how easy the user-side task is, the operation they wanted shouldn't have been performed.

How can I communicate that changing how this system works has risks, particularly when data validity is at stake? I'm a new (6 months) hire and it's become the status quo, but it's risking the validity of our financial data and our support contracts--once the vendor's support hears "X has been customized" that gives them that much reason not to support us or tell us it's our fault.