Plan
Zeno resolves the proposed work against the connected ledger. It checks for duplicates and closed periods, applies confirmed client rules, and renders a plan. Planning changes nothing in the ledger. There is more than one way to arrive at a plan, and they all arrive at the same one:
Feeds and imports stop at this same plan. They do not have a separate posting
path.
Review
A reviewer sees each entry, its source, coding, warnings, and the result of preflight checks. Approval and rejection are explicit verdicts recorded against the exact digest of the plan that was reviewed. A reviewer can also exclude individual lines. Exclusions are part of what the verdict is pinned to, so approving a plan approves the plan as decided, not the plan as it was first rendered.Apply
Only approved entries are sent to the ledger adapter. If the plan or its exclusions changed after the verdict, applying is refused and a new plan is required — Zeno revalidates and stops rather than silently applying a stale plan. Applying twice is refused too: the run already exists. Each entry carries a key derived from its content, so an apply interrupted partway is safe to retry.
Reverse
Each run keeps the provider identifiers and prior state needed to perform the ledger’s native reversal operation. Entries reverse in descending order, voided where QuickBooks voids and deleted where it cannot, and any names the run created are retired last. A cleanup run is journalled with each document’s pre-image before it acts, so reversing it restores a void or an edit onto the same document. A deleted document can only come back under a new id, and the reversal says which it did. Reversal is available regardless of plan tier. Reads and review also remain available when a commercial entitlement blocks a new write.Names go through the same door
A name write is a ledger write. A renamed vendor changes what every check prints; a retired customer leaves every picker. So the name lists — accounts, customers, vendors, employees, products and services, classes, locations, terms, and payment methods — are created, changed, and retired only through a plan (qb_plan_names, or the lists section of qb_plan_batch). There is no
direct tool that creates or edits a name, and an AI client cannot reach one.
The plan is read like any other. Each line says what it does — Create,
Modify, or Deactivate — and names its row exactly. A near match is
refused with the candidates rather than guessed, because retiring the wrong
customer is the one mistake this table must not make on a reviewer’s behalf.
Retirements run first, then changes, then creates, so one plan can retire a
customer and create a vendor under the same name.
Deactivation is the only delete QuickBooks Online offers for a name. The row
leaves every picker, its posted history stays, and a later Modify with
active: true brings it back. For an employee, deactivation is the
termination; a release date can ride on the same line, and it is the only
field a Deactivate accepts. Any other field on a retirement is refused
rather than dropped.
Reversing a names run works by the mirror of each action: a created name is
deactivated (QuickBooks cannot delete it), a retired one is reactivated, and a
changed one gets the touched fields put back from the state the run recorded
before it wrote. A reactivated parent does not bring back the sub-customers or
sub-accounts QuickBooks retired with it; the reversal says so on the line.