Hello,
If you need fault tolerance then Auto it or similar re not exactly the good way, because it relies of given controls being where expected(imagine for example a mouse click generated by Auto it, but at that moment some Windows message window being there instead).
The better ways:
A) If a desktop user interface - using Windows API's to find the app windows handles and interact with them by messaging(or generate keyboard events but only after sure that the right window in focus, etc). (There are some lower lever approaches too but would involve reverse engineering and not good as most application vendors forbid it on license agreements, and no need, what described before would do fine.)
B) If a web based interface, DOM manipulation in a hosted browser control or from a BHO.
-Starting/stopping/logging out from the application doable too(but should be left in a clean state, if a confirmation would be asked on close then would either had to force closing the task or leaving the app opened).
-Using configuration for user, password, and needed option - of course, should not be hardcoded.
-What could help and not breaking any license agreements either, would be spawning the QuickBooks from a parent process that would be more aware about what happens with the child process(think of it as a launcher).
To decide exactly what best would have to take a look at the QuickBooks used version.
To note that radical QB changes (like they remake the UI's) might need changes on your tool too