In the first example, the developer misses the chance for abstraction. The two functions here are apparently exactly the same, so in the words of ‘the pragmatic programmer’ they do have the same information. If they evolve in different directions, though, not all information is the same. The challenge is to find the information that is actually the same, and what information is different, and write smaller functions that take care of the similar bits, or abstract algorithms that may be specialized using some sort of strategy pattern.

In the second example, the issue is bad design, as jft says. Really, the design seems to try to avoid repetition of data, not of code. Persistence and lifetime are issues of objects, not of classes. There is no need to create separate classes for the two instances, it is necessary to create separate objects for the invoice system, that encapsulate the information about the invoice.