The idea of a software "module" has been around for a long time but has never been properly defined. The best we can say is it's a way of splitting software up into more "manageable" pieces and it's an idea that persists in the minds and vocabulary of users and programmers alike. In reality however it is the arbitrary division of software into different "modules" that makes it less robust and flexible and creates an additional burden of work for programmers.
A business software system by its very nature is complex and has numerous interconnections and relationships between its various components. To arbitrarily divide a system into separate "modules" requires the complex interfaces between them to be defined from the outset in order for them to interact. This is not really a problem if the software is unlikely to change however this is not the case for most business software which is normally subject to the need for frequent and ongoing modifications.
A better approach is to develop a business system as a single integrated system and preferably as a single program. Instead of structuring the software into separate "modules" using the arbitrary lines of division specified by a software supplier's marketing department (general ledger, accounts receivable, point of sale etc.) it makes more sense to structure a system using "objects" that represent real business entities (customer, supplier, account, stock item, invoice etc.)
When the structure inside a computer program accurately represents the business it is designed to model the result is maintainable and reliable software that does what we expect it to!