Zoho Books
Your Zoho Books invoices, payments, customers, and items land in DualEntry as AR master data and journal entries. Zoho stays your system of record for AR operations.
Overview
Your AR lives in Zoho Books. Invoices get raised there, payments get applied there, and someone on your team still has to get all of it into the ledger with the right GL accounts and the right dimensions attached. Export, reformat, re-key, reconcile, repeat.
DualEntry connects to the Zoho Books API v3 over OAuth 2.0 and pulls the data itself. Each run works through invoices, then payments, then customers, then items, then locations. Zoho contacts become DualEntry customers, Zoho catalog items become items, invoices become invoices, and customer payments become customer payment records. You map a default income account, a default expense account, and one GL account per Zoho payment mode. After that, every sync reuses those mappings.
The flow runs one way: Zoho Books to DualEntry. The integration is read-only toward Zoho and never posts back, so Zoho Books remains the system of record for your AR operations while DualEntry holds the resulting journal entries. Your Zoho invoice custom fields drive the accounting detail — the Company field routes an invoice to a matching DualEntry company, Location resolves against a Location classification, and Service Line resolves against a classification named Service Type.
There is no third-party connector platform in between. DualEntry built and maintains this integration, authenticating directly against Zoho with the OAuth 2.0 authorization code flow and refreshing your access token automatically when it expires.
Customers (Zoho contacts)
Items (Zoho catalog items)
Invoices
Customer payments
Invoice PDF attachments
Locations
Location and Service Type classification values
Data synced
The integration syncs the following data types:
- Zoho Books contacts import as DualEntry customer records, listed by last modified time and paged until the oldest row on a page is older than the integration creation date
- A detail fetch may run once per contact to fill in the country from the Zoho billing address
- The customer phase gates invoice posting, because a non-draft invoice will not import until its Zoho customer has been mapped to a DualEntry customer
- An invoice referencing an unmapped customer fails with a customer-missing error, then imports on a later run once the customer sync has caught up
- Zoho Books catalog items import as DualEntry item records, fetched in full and paginated each time the item sync step runs
- New DualEntry items created from Zoho default to service type
- Items created from Zoho lines take the default income and expense GL accounts you mapped during setup
- Invoice lines that are not tied to a mapped Zoho catalog item fall back to those same default accounts, so line creation fails while either default is left unmapped
- Non-draft Zoho invoices import as DualEntry invoice records; draft invoices are skipped at detail fetch and only come across once they are finalized or sent in Zoho
- A Company custom field value that matches a DualEntry company name posts the invoice to that company, and anything else falls back to the company the integration is bound to
- Invoice lists page by last modified time, and upserts apply a five-day delta window so late-arriving Zoho edits are picked up on the next run
- Where an invoice carries a Service Line custom field value, line construction follows the service-line path instead of catalog line items
- Zoho customer payments import as DualEntry customer payment records and allocate only against invoices that have already been imported and mapped
- Each Zoho payment mode needs a DualEntry GL account per company before payments in that mode can post, covering Stripe, Check, Cash, Bank Remittance, Bank Transfer, Credit Card, and ACH/WIRE
- DualEntry creates a placeholder payment-account record the first time it sees a given mode and company pair, and a resync applies the mapping to payments captured while it was pending
- A payment with no importable applied invoices fails with a no-importable-invoices error, and the sync requires the payment mode to be present on the list payload plus a detail fetch for the applied invoices
- Zoho business-rule errors such as over-application or a locked period are treated as permanent, so DualEntry marks the payment skipped rather than retrying it forever
- Zoho locations are fetched in full and paginated when the location sync step runs, after the invoice, payment, customer, and item phases
- Invoice custom field values labeled Location become classification lines under a DualEntry classification named Location, which DualEntry creates or updates automatically from the Zoho values
- Invoice custom field values labeled Service Line are matched to classification lines under a DualEntry classification that you must name Service Type; the integration matches on literal string equality with no fallbacks
- Labels and classification line names have to match exactly, including case and punctuation, or the dimension is left off the journal entry rather than guessed
- Renaming the Zoho custom field is the fix when your organization uses different label conventions, because DualEntry will not match alternate labels
- DualEntry pulls the invoice PDF from Zoho's template PDF endpoint and attaches it to the imported invoice
- Attachment is best-effort, so a failure is logged and never blocks the invoice from importing
- A missing PDF usually means the per-sync detail budget was exhausted, Zoho returned a PDF error, or a transient network issue occurred; the invoice still posts and you can review the logs or rerun the sync
Key Features
- Read-only toward Zoho
DualEntry pulls from the Zoho Books API v3 and never writes back. Nothing in your Zoho organization changes because you connected it. - AR master data and transactions in one pull
Customers, items, invoices, and customer payments all arrive from the same connection, so master data is in place before the transactions that depend on it. - Dimensions from the custom fields you already use
Invoice custom field values labeled Location become classification lines under a Location classification that DualEntry creates and maintains for you. Service Line values resolve against a classification named Service Type. - Invoice routing across companies
The integration binds to one DualEntry company, but an invoice carrying a Company custom field value that matches another company name posts there instead. No match falls back to the bound company. - Payment modes mapped once
Stripe, Check, Cash, Bank Remittance, Bank Transfer, Credit Card, and ACH/WIRE each get a placeholder record the first time DualEntry sees them. Map each to a cash or undeposited-funds account and later payments post automatically. - Incremental syncs that respect Zoho quota
Customer, invoice, and payment lists page by last modified time and stop at the integration creation date. A five-day delta window catches late Zoho edits, and a per-sync cap on detail fetches keeps one run from exhausting your daily API quota. - Invoice PDFs where limits allow
DualEntry pulls the Zoho invoice PDF and attaches it to the imported invoice. Attachment is best-effort, so a failure is logged and the invoice still posts. - Connected by OAuth, maintained by DualEntry
Authentication is the OAuth 2.0 authorization code flow against your own Zoho Books organization. DualEntry stores the access token, refresh token, accounts-server URL, and API domain, and refreshes the token automatically. No third-party connector platform is involved.
FAQ
No. DualEntry built and maintains this integration, and it authenticates directly against your own Zoho Books organization using the OAuth 2.0 authorization code flow and the Zoho Books API v3. There is no third-party connector platform sitting between the two systems.
DualEntry stores your access token, refresh token, accounts-server URL, and API domain, and refreshes the access token automatically when it expires. If a refresh ever fails, you reconnect through the same OAuth flow.
Your AR activity stops being an export job. Customers, items, invoices, and customer payments come across from Zoho Books into DualEntry as AR master data and transactions, so the ledger reflects what Zoho already knows without anyone re-keying it.
The dimensions come with it. Invoice custom fields labeled Location and Service Line resolve to DualEntry classifications, and a Company field routes an invoice to the matching DualEntry company, so journal entries arrive already coded rather than waiting on a month-end cleanup pass.
No. The integration is read-only toward Zoho: DualEntry pulls from the Zoho Books API v3 and never posts back. Nothing you do in DualEntry changes a record in Zoho Books.
That means Zoho Books stays the system of record for your AR operations, and DualEntry holds the journal entries, customers, items, invoices, and payments built from that data.
Alongside. The documentation describes Zoho Books remaining the system of record for AR operations while DualEntry receives the master data and transactions, and because the connection never writes back, your Zoho workflows keep running exactly as they do today.
Practically, you keep raising invoices and applying payments in Zoho Books, and DualEntry keeps the ledger, the journal entries, and the reporting dimensions in step with them.
Syncs run on a schedule automatically, and you can trigger one at any time with Sync now in the integration settings, which is blocked only while the integration is paused. Each run works through invoices, payments, customers, items, and locations in that order.
Syncing is incremental: customer, invoice, and payment lists page by last modified time and stop when rows predate the integration creation date, with a five-day delta window on invoice and payment upserts so late Zoho edits get picked up. Zoho publishes a limit of 10,000 API requests per day, so a very large backfill can take several runs across several days. DualEntry caps detail fetches per sync to avoid exhausting that quota, and the next scheduled run resumes where the previous one stopped.
Failures are per record, not per sync, and most of them are self-correcting. An invoice whose Zoho customer is not yet mapped fails with a customer-missing error and imports once the customer sync catches up. A payment in an unmapped payment mode waits for you to map that mode to a GL account, then posts on the next resync. An expired token refreshes on the next API call.
Some things are deliberately permanent. Where Zoho returns a business-rule error such as over-application or a locked period, DualEntry marks the payment skipped rather than retrying the same record forever, so you fix the data in Zoho or accept the skip. Invoice PDF attachment is best-effort: a failure is logged and the invoice still posts. The integration's troubleshooting table maps each symptom to its likely cause and resolution.
.avif)