Consult with your developers, and test the flow yourself.
The developers are often closest to the error problems. They have to keep track of system capacity and failure states, invalid user input, etc.
This is a good opportunity, in that oftentimes error messages are written by the developers with no ux help involved. These errors can end up written from the point of view of the implementation and debugging, and can help devs find out what's wrong.
The problem is these often very technical, or really vague; they can (and do) confuse users:
Map out the errors
Once you get a list (you can use a spreadsheet) you can track it to the flows, and consult with best practices.
From the Error Message Guidelines from the Nielsen Norman Group:
Established wisdom holds that good error messages are polite, precise, and constructive. The Web brings a few new guidelines: Make error messages clearly visible, reduce the work required to fix the problem, and educate users along the way.