Money is the area where a small representational mistake becomes an accounting problem, and the mistake is usually made in the first hour of the project. Floating-point numbers cannot represent most decimal fractions exactly - 0.1 plus 0.2 is famously not 0.3 - and once amounts are stored that way, the error compounds through every calculation until a total is off by a paisa and a finance team cannot reconcile it.
Store money as integers in the smallest unit - paise, cents - or as an exact decimal type where the database provides one. Both are exact; the integer approach has the advantage of being unambiguous across every language and library that touches the data. What matters is that the value which travels between your database, your application, your API and your accounting system is never converted through a float on the way, because a single hop through JavaScript's number type is enough to reintroduce the problem.
Rounding needs to be a decision rather than a default. Where in a calculation does rounding happen - per line item, or on the total? Which direction, and by which rule? The answer is frequently prescribed by tax rules rather than by preference, particularly for GST, and different orderings give different totals on the same invoice. Write the rule down and implement it in one place, because rounding logic scattered across the codebase produces invoices that disagree with the reports about them.
Currency is not a formatting concern. An amount without a currency is meaningless, so store them together and never allow arithmetic between different currencies without an explicit conversion. Not every currency has two decimal places - some have none, some have three - so any code assuming two will misrepresent amounts as soon as you sell somewhere new.
Exchange rates need a stored rate and a timestamp, not a lookup at read time. If you convert on display using today's rate, last year's invoice changes value every day, which makes historical reporting impossible and audit unpleasant. Record the rate used and the moment it applied, alongside the original amount in the original currency, and derive everything else from that.
Finally, money records should be immutable. An invoice that is edited in place has destroyed the history that someone will eventually need to explain. Corrections are new entries - credit notes, adjustments, reversals - which is how accounting has always worked and which gives you a complete trail by construction. Combined with an append-only ledger of transactions, it makes the question of what this account was owed on a given date answerable, which is precisely the question that arrives from an auditor eighteen months later.
