What the product didn't do yet.
Parts of the operational layer cannot be configured into place. They have to be written — against a regulator's schema, a bank's file specification, or a rule that exists only inside one company. This is that work.
Configuration first. Code when it has to be.
Custom code is a liability until it earns its place. We look for the setting, the workflow, or the report that will hold the requirement first — because that is the version the client can own for the next decade without us.
- We build when the requirement comes from outside the vendor — a tax authority's schema, a bank's file layout, a contract term, a process that exists in one company and nowhere else.
- Anything written is documented and handed over. It does not depend on us being reachable.
- What we build is designed to survive the platform's own updates, not to fight them.
Not a demo. The build itself — Zoholics APAC.
Written to specification.
Six of the systems we have been trusted to write. Clients are described, not named — the detail is what matters here.
eInvoice Malaysia — seven document types, not only the invoice
Most e-Invoice implementations submit invoices and credit notes. Malaysia's schema defines eight document types, and ours covers seven of them — invoice, credit note, debit note, refund note, and three of the four self-billed equivalents — each with its own validation path, and 131 checks that run before a document leaves Zoho Books. Taxpayer identification is verified against LHDN as the document is built, and the industry and unit-of-measure code sets are read from LHDN at submission rather than shipped inside the plugin, so they cannot fall out of date between releases. See the plugin →
On the Zoho MarketplaceA signing service for the version that requires one
LHDN's signed submission format is not a checkbox. It is an XAdES signature over canonically serialised JSON, carrying three separate digests that each have to be computed over exactly the right bytes — the failure mode is a document the regulator rejects without explaining why. We built it: certificate handling from PKCS#12, RSA with SHA-256, issuer fields ordered as the specification demands. It runs as a self-hosted service or as a Zoho Catalyst function, because not every client can host one.
Self-hosted or Zoho CatalystA state agency's limit of authority, enforced by the system
Payment authority at a state agency was a document, not a control. We built it into the ledger: approval tiers defined by amount band and configurable without a developer, each tier holding alternative conditions, any one of which satisfies it — two approvers of one role, or a single approver of another. The configuration screen refuses to save overlapping bands, so a payment can never route two ways. Every decision is written against the payment itself, with the approver, the role, and a timestamp in UTC.
Zoho Books extensionThe bank's own file format, rebuilt inside the ledger
Approved payments leave as a bulk-payment file the bank accepts on the first attempt. Six payment modes — intrabank transfer, GIRO, payroll, JomPAY, RENTAS, international telegraphic transfer — each with its own column set and its own rules, checked by 43 validators against the SWIFT, RENTAS purpose, and central-bank reporting code sets. The bank distributes its generator as a macro workbook; we read its checksum logic and rebuilt the whole thing as a widget, so finance never leaves the system they work in.
Zoho Books widgetAn electricity account that reconciles itself
The utility publishes bills to a secure file server and expects payment confirmation returned in a fixed-width layout. Two scheduled functions close the loop: bills arrive as XML and become itemised supplier bills, with rounding carried as an adjustment so the total matches the utility's to the sen; payments go back out in the format the utility's system reads. Bills are keyed on the utility's own document number, so a re-run corrects rather than duplicates — and when a bill total disagrees with the charges the utility stated, the run names the bill.
Zoho Catalyst, scheduledA billing platform for circuits, not products
A connectivity provider bills by circuit, building, and tenancy — a shape no standard invoicing module holds. We built the system it needed: 31 forms and 400 scripts on Zoho Creator, with subscription billing that prorates mid-cycle, survives leap years, and terminates cleanly; pro forma invoices for deposits, deliberately kept outside the submission path they don't belong in; and work orders that open as tickets in Zoho Desk. LHDN submission is built into it, not bolted beside it.
Zoho Creator
Built, then explained — Zoholics APAC. Further builds available on request, under NDA.
The platforms we extend.
Custom work is only as sound as the ground under it. Ours sits on the Zoho platform — extensions and widgets inside Zoho Books, applications on Zoho Creator, serverless functions on Zoho Catalyst, and the Deluge logic that ties them to the rest of the suite.
Alongside Zoho, not merely on top of it.
"We do not optimise for the engagement. We optimise for the decade after it."
Custom code that nobody maintains becomes the next system to replace. Every build above is documented, and every one of them comes with a way to reach us after launch.
Describe the rule nothing holds.
If it exists only inside your company, it can still be built properly.