Zoho Inventory + CycleForge
Zoho Inventory holds the purchase orders, the item master, and the accounting truth. CycleForge runs the physical work against it — so receiving a box updates the PO instead of creating a second set of numbers someone reconciles later.
Receive against the real purchase order
When a carton hits the dock, CycleForge resolves it to an actual Zoho purchase order and unboxes against those line items — not against a copy typed into a spreadsheet. The operator sees what was ordered, what has already arrived, and what is still outstanding on that PO.
Marking a line received pushes a purchase receive back to Zoho. That is the step that usually gets deferred until month-end and then done from memory. Here it happens at the moment the box is opened, by the person holding the contents.
Receives can also be reversed. A mis-scan returns the PO to issued rather than leaving a phantom receipt that someone has to unpick in the accounting system.
Partial shipments stay honest
Vendors under-ship, split shipments across boxes, and send the rest three weeks later. CycleForge tracks warehouse-received totals per PO line item, so a partially received line shows what actually arrived against what was ordered.
The practical effect: an operator opening the second box of a split shipment sees the remaining quantity, not the original order quantity — so the same units do not get received twice.
One item master, not two
Items are read from and written back to Zoho, so the SKU an operator scans at the bench is the SKU accounting knows about. SKU lookup is deliberately forgiving about leading zeros — a scanner reading 0001234 still finds item 1234, which is the sort of mismatch that otherwise stops a receiving line dead.
Multiple warehouses are supported, so stock resolves to the location that actually holds it.
Shipped orders push back
Outbound completes the loop: shipped orders sync out to Zoho so the accounting chain reflects what left the building. The floor stays the system of action; Zoho stays the system of record.
When Zoho is slow or down
A warehouse cannot stop because an API is having a bad afternoon. The Zoho client runs behind a circuit breaker: repeated failures trip it, calls stop hammering a struggling endpoint, and it retries on a backoff. Connection health is a live check — CycleForge mints a real token to confirm the connection works, rather than assuming stored credentials are still valid.
What it does not do
- It is not a replacement for Zoho. Purchase orders are created and managed in Zoho. CycleForge receives against them and pushes results back — it does not try to become your inventory system.
- It does not sell. Zoho is connected as the inventory backend. Sales channels — eBay, Amazon, Shopify, Square — are separate connections.
- It does not run a background mirror of your catalog. Purchase orders and items are read when the floor needs them, so operators see current data rather than the state of a nightly copy.
Connecting it
Connection is OAuth against your own Zoho organization, with tokens stored encrypted per tenant and refreshed automatically. Connect from Settings → Integrations. Zoho Inventory is currently the inventory backend CycleForge supports; surfaces that need one will prompt to connect rather than failing with an unexplained error.