From time to time we like to remind people that formatting matters. And what better way to scare you into paying attention than to burn down your house? Not because you left the heater too close to the drapes. But because a windstorm ripped the power cables off the front wall, set fire to your favorite shrub, which then set fire to your house.
That's covered by your insurance, right?
Well actually, it all depends. And believe it or not, it might depend on formatting. A single clause formatted one way could give you 100% cover. The exact same words formatted differently could leave you with nothing.
Let's suppose your policy was worded like this:
Example I: You Lose
In Example I, you are covered for fire and flood, "except when arising from windstorm". Importantly, the exception starts on a new line, which is aligned with the opening words of the clause. This makes it clear that the exception qualifies both of coverages (a) and (b). Which means you are not covered for fire because it arose from a windstorm. Which means you lose, and your insurer wins.
But what if we make one small change so that your policy now looks like this:
In Example II, the words "except when arising from windstorm" are indented to line up with the text of coverage (b). This makes it clear that the exception qualifies only coverage (b). Which means only flood is subject to the exception, and fire is still covered. Which means you win, and your insurer loses.
And finally, what if we roll the whole clause into a single paragraph with no formatting at all, so that it looks like this:
The effect of this change is to make it completely ambiguous as to whether the exception applies to fire and flood, or just flood. So maybe fire is covered, or maybe it's not. The lawyers will have fun arguing about this for months, maybe years (depending on how much your house is worth). And whoever has the best the lawyers wins.
What does any of this have to do with document assembly?
It's a risk that business users need to be aware of when their developers tackle document assembly as "just another database application", where a document is just a set of clauses, and a clause is just a set of words, and as long as the correct words are rendered to the page, everything is OK. This approach may work for printing statements and invoices, but as Example III illustrates, it does not work for contracts, insurance policies and finance agreements, where formatting matters.