I'm going to describe my experiences from the point of view of a project manager in Information Services. Some of the specifics might not exactly match your specific environment, but the principles are still the same.
This sounds like a classic case of breakdown in communication between the business resources and the technical resources. This can also be a symptom of poor design and poor communication during the early phases of the project.
These "emergency" changes usually stem from features that are perceived to be "missing" from the final product; i.e. The final user expected a feature that isn't there. This is usually the product of a lack of understanding about what the final product will consist of. It is so, so easy for the project team to say "Ok, here's what we need to make. This is what we talked about, this is what they want. Let's get to it." Everyone puts their nose to the grindstone and hammers out a product based on the initial design specs. However, as we all know, the final users typically:
Do not have a firm idea of what the final product is going to look like
Change their mind mid-project cycle and expect the technical team to read their mind and know exactly what they "really" wanted
To alleviate some of these emergency changes, there are a few things you can try.
Have frequent meetings (in-person, phone, video chat, etc.) with the final users to discuss progress on the project and current features. Make sure that everyone is on the same page during each interaction and stress what progress you've made so far and what features the users should expect by the next interaction.
Include the final users in all testing steps leading up to release. Make sure the users understand that the product is still in development, but include them in what progress you've made so far. The more interaction the users have with the product prior to release, the more understanding they will have of what to expect from the final product.
Document all discussed features and get sign-offs on everything. Write down every feature, produce mock-ups, and make sure that everyone involved in the final product has a firm idea of the rough final product. Having hard documentation of exactly what the users should expect from the final product, coupled with user approval (even if it's by email), will go a long way toward my next point:
Be able to say "No." Now, I understand this might be harder when you're producing products for external users, especially if you rely on their repeat business. However, having documented approvals of the features that will be included with the final product will assist you in your argument. If saying "No" is not an option, simply be realistic with the user. You're likely moving on to other projects that have also have a strict deadline, and the user needs to understand that you can only do so much. Add only the essential extra features, but remind the users that in the future, they need to document all necessary features up front while the product is being produced. Hurried "fixes" and "additions" to the final product will often result in a decrease in quality.
As far as "contractual" language, well, an actual contract would be your best bet. If you're able to document exactly what features the users expects, and get everyone on the same page during initial planning and design, then my personal opinion is that it's entirely acceptable to ask the client to sign a contract. Included in that contract should be the features the team has discussed during planning and design, as well as a hard cut-off date on when new features can no longer be requested. Optionally, you can also include a clause stating that any new features requested after the cut-off date will result in additional negotiations for price on those specific features being added to the final product.
For the actual contracts themselves, you can draft your own and put in the specifics I've listed above. You can also edit an existing template to fit your needs. Some templates can be found on 10 Freelance Web Design Contract Templates and Samples by develop-a-website.com.
No matter which you choose to do, I would also get a legal entity to evaluate it for soundness.
I hope that this has helped. If you need me to elaborate on any of these, or if you need additional information, let me know.