Context
Finvo is an e-invoicing platform built around Malaysia's LHDN MyInvois requirements. When a country introduces mandatory e-invoicing, an invoice stops being a document a business can format however it likes: it becomes a record that has to be structured, submitted and validated before it is considered valid.
That shift changes the business process, not just the software. My analysis focused on what the mandate means for the people who issue invoices day to day, and what the product therefore has to do.
Scope of Analysis
- Compliance requirements: what the mandate obliges a business to do, translated into system behaviour
- Business workflows: how invoicing works before and after the requirement applies
- User needs: who issues invoices, what they know, and what they should not have to know
- System behaviour: validation, submission, rejection and correction paths
- Product functionality: which capabilities are essential versus desirable
Compliance products carry a specific risk: the requirement is set externally and is not negotiable, but the users are ordinary businesses who did not ask for it. The product has to satisfy the regulation while remaining usable by someone whose job is running a business, not interpreting tax rules.
Problem areas examined:
- • Externally fixed rules: the required data and its format are defined by the mandate, so the product cannot simplify them away — it can only decide how much of that complexity the user has to see.
- • Process change, not just tooling: validation and submission introduce steps that did not exist in the previous invoicing routine.
- • Failure handling: a rejected submission is a business problem, not only a technical error — the invoice still needs to reach the customer.
- • Varied user maturity: some businesses issue a handful of invoices a month by hand, others generate them from an existing system.
Framing the real problem
The user's goal is not “to comply” — it is to invoice a customer and get paid, without the invoice being rejected. Compliance is a constraint on that goal. Framing it this way puts the design attention on preventing invalid submissions rather than on reporting them after the fact.
Interested in discussing this analysis?
Open to Business Analyst, Business Systems and Product Analyst roles