Running your delivery schedule in a spreadsheet next to your accounting system? There's a better answer. Get a free automation audit

The Challenge

Nothing was broken. Zoho Books worked exactly as designed, and the design didn't match the business.

1. One order, one delivery date, one problem. A purchase order in Books carries a single delivery date. A real supply contract delivers line one in March and line four in June. Businesses in this position do one of two things, and both are bad: split every contract into a dozen separate POs until nobody can see the whole order, or track the real schedule on a spreadsheet beside the accounting system. Within a few months the spreadsheet and the ledger disagree, and the spreadsheet is the one people trust.
2. One sale, several suppliers, no link between them. A single sales order was routinely sourced from multiple vendors. Out of the box, that relationship isn't modelled, so the connection between what was sold and what was bought against it lived in somebody's head.
3. Costs by month, not by project. Finance could close a period. What it couldn't do was tell you what a specific project had cost, because purchases and bills weren't tagged to one. On project-based contracts, that is the number that decides whether the work was worth doing.
4. Everyone could edit everything. No restrictions by hierarchy, no audit log. In a finance system, that isn't a control gap so much as an unanswerable question when a figure changes.

What We Built

Zoho Books stayed the finance system. We customised the parts that didn't fit and added Analytics on top for the reporting the business couldn't get from the standard views. No new platform, no migration.

A delivery schedule that lives on the line item

• Separate delivery dates for every line item on both purchase orders and sales orders, so one document holds the whole staggered schedule instead of being split into several.
• Real-time purchase order status, visible as the order progresses rather than reconstructed at month end.
• Automated notifications for POs sitting pending or waiting on approval. Approval bottlenecks are usually invisible until someone chases a late delivery.

One sales order, several purchase orders

• Multiple PO generation from a single sales order, with the link between them preserved, so the business can answer "what did we buy against this sale, and from whom?" from the record itself.

Financial tracking by project, not just by period

• The project tab enabled across purchase order and bill workflows, so every cost carries the project it belongs to.
• Automated tax calculation with compliance tracking.
• Invoice, payment and reconciliation workflows tightened so the month-end close stops depending on one person's memory.

Reporting the standard views don't give you

• Reports on open sales orders filtered by customer, date and other criteria — the view a sales or operations lead actually asks for.
• A real-time dashboard covering sales and purchases together.
• Zoho Analytics connected to Books with live data sync, for sales and purchase trend analysis across periods.

Controls that hold up

• Role-based access controls, with edit restrictions following the user hierarchy.
• Audit logs, so a changed figure has a name and a timestamp against it.

Results

• The schedule lives in the finance system. Line-item delivery dates on POs and sales orders, so the ledger and the delivery plan are the same document.
• Sales and purchases are linked. One sales order can raise several POs and the relationship survives.
• Cost by project is a report, not an exercise. Purchases and bills carry their project through to reporting.
• Changes are attributable. Hierarchy-based edit rights and audit logs across the finance data.
• Live in 4–6 weeks across five milestones, with UAT and training before go-live.

Why It Worked

We customised the software instead of replacing it. That sounds obvious. It isn't what usually happens.

When accounting software doesn't fit how a business sells, the instinct is to go shopping — a mid-market ERP, or a custom-built application to sit alongside. Both are ten times the cost and a year of the team's life, and both are usually the wrong answer to what is really a configuration problem. Books already handled the tax, the invoicing and the ledger properly. It just modelled delivery as a single event. That gap is worth four weeks of work, not a platform migration. Books stretches further than most teams expect: our cross-border CRM and Books build ran one deal flow across two countries on it.

The second thing that kept it to four weeks was what we refused. Historical data import, third-party integrations and marketplace apps were all put explicitly out of scope at the start, in writing. Every one of those is easy to say yes to during a sales conversation and every one of them is how a six-week project becomes a six-month one. Scoping them out isn't unhelpfulness. It is the reason the client got a working system in May and not an argument in October.

Frequently asked questions

Facing the same challenge?

If your finance system can't describe how you actually buy, sell and deliver, we'll show you what it takes to close that gap — usually without changing platform. Start with a free automation audit. Get a free automation audit