The problem

We run Zoho Books with two e-invoicing integrations: myData (Greek tax authority, AADE) and PEPPOL (EU e-invoicing). Between the two, our Invoice form carries a large number of custom fields — document type codes, VAT exemption categories, payment method codes, counterparty classification, endpoint IDs, tax representative details, and more.

The problem: every field is visible to every user on every invoice, all the time. There is no way to group them into sections, show them conditionally, or make them mandatory conditionally on the Invoice form.

Our invoices are created by salespeople, not accountants. They open the invoice form and face a wall of 40+ flat custom fields with no indication of which ones apply to the document they're creating. The result is predictable: wrong fields filled, mandatory regulatory fields left empty, and e-invoices rejected by myData or the PEPPOL access point — errors that surface after submission, when they are expensive to fix.

Real-world examples of what we need

• If Invoice Type = "1.1 – Sales Invoice" → show the myData classification section; hide the retail receipt fields.
• If Customer Type = "EU B2B (PEPPOL)" → show PEPPOL endpoint ID, buyer reference, and order reference fields, and make them mandatory.
• If VAT Exemption Category is selected → make the exemption reason code mandatory and pre-fill the related article reference.
• If Payment Method = "Bank Transfer" → pre-fill payment terms and show the bank detail fields.

Every one of these is a conditional show/hide, conditional mandatory, or conditional pre-fill — exactly what layout rules do.

The frustrating part: Zoho Books already has this feature

In the June 2026 update, Zoho Books shipped Layout Rules for Custom Modules — conditions with Show Fields, Enable Fields, Set Field Value, and Set Field as Mandatory actions. It's well designed. It's exactly what we need.

But it only works on custom modules. The modules that actually need it — Invoices, Credit Notes, Bills, Quotes, Sales Orders — are excluded. These are the forms where regulatory complexity lives and where non-accountant users do their daily work.

Zoho CRM has had conditional layouts and layout rules for years. Zoho Desk has them. Zoho Recruit has them. Zoho Forms has field rules. Books custom modules now have them. The Invoice form — arguably the single most regulation-heavy form in the entire Zoho ecosystem — has nothing.

Request 1: Extend Layout Rules to standard transaction modules

Take the existing custom-module Layout Rules engine and enable it on Invoices, Credit Notes, Bills, Quotes, Sales Orders, and Purchase Orders. Same UI, same four action types. Additionally:

• Field sections/groups on transaction forms, so related custom fields (e.g., "myData Classification", "PEPPOL Details") can be visually grouped and collapsed — like sections in CRM layouts.
• Conditions should support the Customer's fields (e.g., customer type, tax treatment, country), not just the invoice's own fields, since most e-invoicing logic branches on who the customer is.

Request 2: Client Scripts for Zoho Books

Layout rules cover declarative cases. For anything beyond that — cross-field validation before save, computed field values, lookups against an external service while the user is still on the form — we need what Zoho CRM already offers: Client Scripts (JavaScript on form events: onLoad, onChange, beforeSave).

Concrete use cases from our e-invoicing setup:

• Validate that the combination of invoice type + VAT category + exemption code is legal under myData rules before the user saves — not after AADE rejects the document.
• Check a customer's PEPPOL endpoint ID format (ISO 6523 scheme prefix) on field change.
• Auto-derive the myData classification from the item category and customer type as line items are added.

Workflow rules and custom functions run after save — too late. Validation Rules in Books are single-field and can't express cross-field regulatory logic or call out to reference data. The gap between "form opens" and "record saved" is exactly where compliance errors are born, and today there is zero extensibility in that window.

Why this matters beyond Greece

e-Invoicing mandates are rolling out across the EU (Germany, France, Belgium, Poland, Romania, Spain...) under ViDA, plus similar regimes worldwide. Every one of these adds conditional, regulation-driven fields to the invoice form. Every Zoho Books customer in these markets will hit this wall. The companies most affected are exactly the SMBs Zoho Books targets — they don't have accountants creating invoices; they have salespeople. Its not just e-invoicing/ peppol, the things above, are well needed in general.

The engine is built. Please turn it on where it's needed most.

Has anyone else run into this with e-invoicing fields? +1 if you'd use layout rules on Invoices.