Accrual Automation for Zip

The Short Answer

That distinction is the whole point of this page. Zip gives finance an unusually early view of committed spend. Getting from that view to a defensible journal entry, booked in the right period and reversed the next, is still work Zip was never built to do, and the close has little slack to absorb it. The median monthly close runs 6.4 calendar days, with top performers at 4.8 or fewer, per APQC benchmarks.

What Zip Already Gives Finance

Zip is an intake and procurement orchestration platform. It gives any employee a single front door to request a purchase, then routes that request through the right approvals and captures purchase and vendor data at the request stage, before a purchase order is generated. In Zip's own words, it lets you track purchases from request to approval for a full picture of committed spend.

For a finance team, that is genuinely useful, and it is worth being precise about why. You get vendor and amount detail captured at intake, an approval record that shows who signed off and when, and requests matched against budget. By the time a purchase order is cut, the commitment has already been visible in Zip for days or weeks. That is earlier than a PO-based or invoice-based view, which is exactly where most accrual signals start.

Why Zip Alone Leaves the Accrual Open

A commitment is not an accrual. An approved request tells you money will be spent. An accrual records an expense that has already been incurred but not yet invoiced. The gap between those two is judgment that lives in finance, not in procurement orchestration.

Three mechanics keep the accrual open even when Zip has done its job well. First, timing: a request approved in June may cover work delivered across June and July, so someone has to decide how much belongs in the June close before any invoice arrives to settle it. Second, coverage: not every incurred expense starts as a Zip request, and a vendor confirming delivery by email or a contractor who was engaged informally never enters the approval queue at all. Third, the ledger: Zip does not post journal entries, hold your accrual policy, or reconcile committed spend against the general ledger, so the entry, its reversal, and the true-up remain a manual step at close, usually in a spreadsheet. Field audits cataloged by the European Spreadsheet Risks Interest Group have found errors in roughly 90 percent of operational spreadsheets, which is the quiet risk of running accruals by hand.

None of that is a shortcoming in Zip. It is the line between orchestrating a purchase and booking the accounting for it, and the second half is where close time still goes. For the cases with no invoice yet, our guide to unbilled accruals covers the estimation methods auditors expect.

What Mesh Reads From Zip, and How

Mesh integrates with Zip through its API and reads the full lifecycle of a purchase request: the request itself, the approval queue, the purchase order once it exists, and the invoice when it lands. The approval queue is the part that matters most here. Because Mesh sees a request the moment it is approved, it can recognize a committed, incurred expense before a purchase order is cut and long before an invoice arrives.

Mesh then applies your accrual policy to that signal, the same logic every period, and stages a journal entry for review with the amount, the account, and the supporting detail attached. It posts the approved entry into your ERP, whether that is NetSuite or another ledger, and keeps version-controlled logic so the number is reproducible at audit. Zip stays your procurement system and your system of record does not change.

Zip is not the only place a signal lives, so Mesh also monitors email, Slack, Teams, and the AP inbox for the incurred expenses that never became a Zip request. If you are also comparing tools that sit on your ERP itself, our roundup of accrual tools that layer on NetSuite covers that layer.

One Accrual, From Approval to Close

Take a single case. On June 10, an engineering manager submits a Zip request to engage a security-audit firm for a June penetration test, 30,000 dollars, and it clears approval on June 12. The firm does the work through the month. At June 30, the test is complete, no invoice has arrived, and the purchase order is still pending.

Here is what each system sees. Your ERP shows nothing: no invoice, no expense, no entry. Zip shows an approved request for 30,000 dollars, with the vendor, the requesting manager, the approver, the approval date, and the GL coding all captured at intake. The expense clearly belongs in June under the matching principle, but the only record that it exists at all is sitting in Zip's approval history.

Mesh reads that approved request from Zip's approval queue, applies your policy for professional services, and stages a 30,000 dollar accrual to the right expense account and department, with a reversal dated for the start of July. When the invoice arrives on July 9, Mesh trues up the difference. Afterward, an auditor pulling the June entry sees the traceback in one place: the Zip request ID, the approver and date, the amount, the department it rolled up to, and the July invoice that settled it. The estimate that used to depend on someone remembering to check the approval queue during close week was captured the day it was approved.

What Still Takes a Person

This is not full automation, and describing it that way would not survive a first close. A person still decides whether an approved commitment was actually incurred by period-end or belongs to the next one, sets the materiality threshold below which an accrual is not worth booking, and reviews anything that moved unusually against prior periods. Mesh flags the exceptions, a missing assumption, a request with no clear delivery date, an amount well outside the vendor's history, and routes them for review rather than guessing. The controller keeps the sign-off.

Frequently Asked Questions