The use of transactions should pay off here. If any issues arise, don't commit the changes being made, simply roll it back to either the beginning or at a another point in time (break it up into multiple transactions with tables for each step). If you use additional tables for each step in your process, you can go through the data changes made at each point and pinpoint where the error occurred.
Based on the feedback you had given me for my original answer. We know a few things about you environment:
(1) It's a corporate environment where there is little communication between teams. This is evidenced by the fact it appears to be difficult for you to obtain log files from the DBA team.
(2) It's a behemoth of a system.
Before you can fix a problem, you need to understand it. In your case, getting the log files and keeping a diary/journal of the errors and types of errors you are getting will give you a better idea of what's happening. Are you getting data entry errors? Is there data missing? Is referential integrity being violated anywhere? If you can theme the errors, you will have a better understanding of what is going wrong. If getting the logs is as troublesome as you say, speak to your manager about the problem and ask him if he can obtain the logs for you. In a corporate environment, people tend to be very territorial about their work and don't answer to everybody as they are probably under a lot of stress with minimum bandwidth to deal with other issues. If the request comes from someone higher up, you may get a more positive response.
Once you have got the log files and managed to theme the problems, you should have a second discussion with your manager. Give him feedback on what you have found and suggest two or three solutions to resolving this. Outline the short term and long term benefits of each, providing a rough estimate of how long you believe it would take to implement. The key here is communication. Your replies to my initial answer indicate there is a complete lack of it, so you need to make a strong effort to promote it. Having your manager supporting you will give you an additional medium to communicate with the DBA team as he can speak to their manager if they become unresponsive.
If all this fails and you are unhappy with the situation, my only other advice is that you look for another place to work. I've found this situation happens in many companies and to different degrees, and it can boil down to a case of how much you can tolerate. After it happened to me a few times, I came to the conclusion that it simply was not my company and the issues that came up were down to management. If it made life difficult for me, I'd simply move on to other things. Life is too short.
Obviously, you can make use of the standard log files that come with your DBMS on-top of this, but if your company operates under a "hurry up mantra" with regards to getting stuff out the door and it's causing a lot of delays, you should make an effort to discuss these problems with management. Show them what their ignorance of testing is costing them.