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 first look for the setting, workflow, or report that can meet the requirement, 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.
Working on the build itself at Zoholics APAC.
Written to specification.
Six of the systems we have been trusted to write. Clients are described rather than named, because 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 has its own validation path, and 131 checks 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. Get one wrong and the regulator rejects the document without saying 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
At a state agency, payment authority existed only as a document. We built it into the ledger: approval tiers defined by amount band and configurable without a developer, each tier with 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. There are six payment modes (intrabank transfer, GIRO, payroll, JomPAY, RENTAS, and international telegraphic transfer), each with its own column set and 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. When a bill total disagrees with the charges the utility stated, the run names the bill.
Zoho Catalyst, scheduledLHDN e-Invoicing, built into a billing system already running
A connectivity provider bills its tenants from its own application on Zoho Creator — fixed and call charges, a shape no standard invoicing module supports. We did not replace it. We built LHDN submission into it: invoices, debit notes, credit notes, and refund notes signed and submitted from inside the application, a refund-note module where none existed, and pro forma invoices for deposits, kept out of the submission path on purpose.
Zoho Creator
Built, then explained at Zoholics APAC. More 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.
Working alongside Zoho at Zoholics APAC.
"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. Each build above is documented and comes with a way to reach us after launch.
Where we deploy it.
Describe the rule no product covers.
If it exists only inside your company, we can still build it.