The SOW describes how the business works–business transaction by business transaction

Sellers must do the work of how best to map a company’s business transactions to their enterprise software solution.  However, it is unrealistic to the highest degree to expect them to do this in a vacuum: the SOW-owners, at all levels, must participate in this process, or it simply won’t be done correctly. The important point is that this early, presale mapping activity is the only proper place in the entire process for discovering functional gaps. In no event is it tolerable for any abstract requirement to be glossed over, and in no event must a potential seller feel that it will be penalized for announcing a gap. For example; if the proposed system does not have any built-in transaction that permits the adjustment of sales commissions from journal entries, then the requirement must be jointly explored to see how it can be satisfied (custom code, workaround, and so on). Such sticking points are inevitable but they are also highly desirable, because no off-the-shelf solution ever matches the buyer’s expectations exactly. Sellers must be convinced of this point up front, or they will revert to the time-honored practice of just saying (in this case), “Yes, a JE42 entry does all that and more” and then move on to the next abstract transaction.

In ERP projects, the SOW-building process is mostly about discovering (and negotiating) the critical expectations that must be met if the system is to succeed.