Story

Designed, not bolted on: the thinking behind Cloudby’s e-Invoice

Abstract isometric blueprint of an invoice drawn as a connected system, in navy and cyan

It is January, and for the first time in a long while, I can exhale from rigorous testing and integrating with LHDN e-invoice API.

A handful of businesses are now running their daily e-Invoice operations on Cloudby. Real submissions to LHDN, every working day. That quiet hum of things simply working is the best feedback a builder can get, because it means the design held up under real life. So while I finally have a moment, I want to share how I thought about it.

e-Invoice could have been a checkbox. I chose to treat it as a design problem instead, and that choice shaped everything.

Strict where it counts

Here is the first decision, the tandem design, book’s document with IRB’s eDocument. In Cloudby, when you confirm an invoice it does not immediately land in your books. It waits until LHDN has actually accepted it. If the tax authority rejects it, the invoice steps back to draft so you can fix it. Only once it is accepted does it post to your books.

The decision

Your accounts should never quietly claim something the regulator refused. So I wired e-Invoice acceptance into the accounting itself, instead of treating it as something that happens afterwards. The official record and your books can never drift apart.

But business is get paid first, paperwork later

The hard part of design is not being strict, and it is not being flexible. It is being both at once, without confusing anyone.

Strictness on its own would make a system that is correct and unbearable. Real business does not pause for administration. Sometimes you simply need to get the invoice out and receive the money, then sort the finer details, the buyer’s tax number (TIN), the classification code (MSIC), when you have time.

So right next to all that strictness sits a simple switch: DEFER. One click, and you can issue the invoice now and handle its e-Invoice formalities when you are ready.

An e-Invoice is not your invoice

This one sounds like a technicality, but it is the quiet decision that made everything else possible. I kept the official e-Invoice as its own record (eDocument), separate from the everyday invoice (document) you work with.

Keeping them apart meant the official document could stay perfectly faithful to what was submitted, while your working book’s documents stayed flexible. It is also what let me handle the messier realities cleanly. Documents you receive from suppliers. Self-billed documents, where you issue on behalf of someone else. Consolidated submissions at month-end. None of those fit a world where the e-Invoice is just a copy of your invoice. They all fit easily once it is its own thing.

An official, locked document beside a flexible, editable working document, linked together
Keeping the e-Invoice as its own record: the official document stays locked and faithful to what was submitted, while your working document stays flexible.

Designing for clarity, not just correctness

The part I am most quietly proud of is a small dashboard that looks almost too simple. e-Invoice has a way of scrambling people’s heads. Who is the issuer, who is the sender, who is the seller, is this income or expense, am I sending or receiving. Mix up any two and you make a mess. So I laid it out as a grid.

You issue it
You receive it
Income
Sales invoiceYou bill a customer
Self-billed invoiceIncome you record, but receive
Expense
Self-billed invoiceYou issue it to a supplier
Supplier invoiceA supplier bills you
One glance answers two questions at once: are you issuing or receiving, and is it income or expense. Self-billed documents are the ones that break the tidy four, and the grid still gives them a clear home.

At a glance, anyone, including an accountant who has never seen Cloudby before, can tell exactly what each document is. Clarity was the goal.

Less to do at month-end

Two more decisions came from the same instinct: take work off the user’s plate later. You can mark individual invoices for consolidation as you go, then bundle them all and submit at month-end without hunting them down. And when a document comes in, you can attach it and settle it right there, so it does not pile onto your reconciliation weeks later. Small choices, but they add up to calmer month-ends.

The quiet payoff: nothing to explain

Cloudby pulls in received documents every day, so what is inside Cloudby always matches what is sitting in the LHDN portal. It works in tandem between the two, which means there is nothing to reconcile and nothing to explain.

If an officer ever comes asking, the answer is simple. Everything is here, and everything is by design.

Detailed line-art blueprint of an integrated multi-currency and e-invoicing accounting system.
The whole system on one page: documents, ledger, multicurrency and reconciliation, designed to hold together.

Why I build this way

I would rather see it as the process of invoicing should works seamlessly with e-invoicing, seamless journey, non-blocking, always in sync. And yet with enough flexibility to Defer, robust enough to Detach & Reattach, so my users using Cloudby do not have to think at all. Get the mental paradigm right, and everything else comes intuitively. Compliance should feel like a by-product of a well-designed system, not a second job. Watching those first businesses run their daily e-Invoice tells me the approach was right. And now, finally, I can turn to the next hard problem.