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 DBAs.
(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 can 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 some and a rough estimate of how long you would think it would take to implement. The key here is communication. Your replies to my initial answer indicates 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 DBAs 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. This issues happens in many companies and to different degrees, so it's down to whatever you can tolerate. After it happened to me a few times, I came to the conclusion that it simply wasn't 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. I've been in a similar scenario in a corporate environment and it was always about short term benefits and they never thought about looking at the existing business logic and improving it.