First, define the final data validations, then define and design all the ledger and auxiliary tables (for example, Registers, Posted Document tables, and so on). At this point, we are determining what the permanent content of the Posted data will be. If we identify any new supporting table or table reference requirements at this point, we should go back to the first step to make sure that this requirement didn't need to be in the design definition.

Whatever variations in data are permitted to be Posted must be acceptable in the final, permanent instance of the data. Any information or relationships that are necessary in the final Posted data must be ensured to be present before Posting is allowed to proceed.

Part of the Posting design is to determine whether data records will be accepted or rejected individually or in complete batches. If the latter, we must define what constitutes a Batch; if the former, it is likely that the makeup of a Posting Batch will be flexible.