Skip to main content
Unlisted page
This page is unlisted. Search engines will not index it, and only users having a direct link can access it.

Parallel Run — Controller Guide

Retired 2026-09-05. The Parallel Run page this guide describes was removed from the product, and the route it names no longer exists. The guide is kept for the record of how the parallel run was measured; it does not describe a live screen. For what still applies, see the Cutover guide.

Parallel Run answers one question: are we ready to retire the legacy ERP? While both systems run side by side, Arcvue codes every transaction independently and then compares itself against what the legacy system did. This guide explains what the numbers mean, which ones actually decide the outcome, and — the part that costs real money if you get it wrong — what you must never do to make them look better.

For: controllers and anyone accountable for the cutover · Time: ~15 minutes · You'll need: the Accounting module, and both sides flowing — Arcvue's own coding, and the feed from the legacy system it is graded against.

Where this used to live​

The screen is gone. Until 2026-09-05 it was at Accounting → Compliance → Parallel Run (/parallel-run); the nav entry, the route and the page were all removed together. Nothing replaces it as a screen, because the question it answered has been answered — for the decision it fed, see the Cutover guide.

Everything below is kept as the record of how the parallel run was measured. Read it in the past tense.

Part 1 — The one idea that matters most​

The legacy ERP is the answer key. It is never the source.​

Arcvue codes each transaction on its own, from the evidence: the bank feed, the card feed, the vendor, the timecard, the contract. Only afterwards does it compare its answer to the legacy system's.

That ordering is the whole point of the exercise. If Arcvue simply copied the legacy coding, agreement would be 100% and would prove nothing at all.

So the corollary is a rule, not a suggestion: never "fix" a disagreement by changing Arcvue's coding to match the answer key. A coding changed to agree, without understanding why it disagreed, makes the percentage better and the system worse — and it will diverge again on the next transaction of the same shape, except now nobody is looking. If Arcvue is wrong, fix the reason it was wrong. If Arcvue is right, say so explicitly (see Accept: Arcvue right).

The gate is three legs, and people usually only watch one​

All three must be true at the same moment. There is no partial credit and no weighting between them:

LegWhat it means
30-day agreement at or above 95%Over the trailing 30 days, on transactions present in both systems, Arcvue reached the same answer as the legacy system at least 95% of the time
No persistent feed gapsNothing the legacy system booked is persistently missing from Arcvue
Trial-balance tie-out passingAt least one real month ties, with nothing unexplained

"The percentage looks great but the gate is red" is the most common confusion, and it is not a bug. The three legs measure different things. A tenant can agree on 99% of what it sees and still fail — because something the legacy system booked never arrived at all, or because no month has tied yet.

The trial-balance leg blocks on its own, and it is the one people forget. It is deliberately strict: it requires a month that genuinely tied. A tie-out that has simply never run does not count as "not failing" — it blocks, on the principle that never having asked the question is not the same as having answered it.

It is a 30-day cumulative lookback, not a streak. A single bad day does not reset a counter to zero; it dilutes a 30-day average, and it washes out as the window rolls past it. The gate additionally requires at least 30 days of run history, so a young parallel run reads insufficient history rather than pass or fail. Projected readiness extrapolates the current trend to the date the rate would cross 95% — a forecast, not a countdown.

One subtlety worth knowing, because it explains a gate that passes on a day the tiles look short: the bar is measured against the effective rate — raw agreement plus the conflicts you adjudicated as Arcvue right. The raw rate stays on screen for transparency, so the two can differ, and the gate acts on the effective one.

Two categories are excluded from the verdict, on purpose​

  • Bookkeeper ahead — Arcvue booked something the legacy system has not yet. Being early is not an error.
  • Excused legs — work the legacy system produces that Arcvue is not expected to reproduce from evidence.

Excluding them is a stated judgment, not a thumb on the scale, which is why each excused category is broken out by reason rather than hidden inside a total.

Part 2 — Reading the screen​

Filters first​

Entity, Source and Txn type come from the data itself and apply to both the roll-up and every drill-through. So a filtered percentage is a real percentage of that slice — useful when one entity or one feed is dragging the number.

When any filter is set, a Clear link appears beside them and resets every one at once. It is only shown while something is filtered, so its absence means you are looking at the full population.

Arcvue's side​

TileWhat it counts
MatchedPresent in both systems — the only population the percentage is computed on
AgreedMatched items where Arcvue picked the same account
ConflictsMatched items where the two disagree. This is the work.
Accepted (Arcvue right)Conflicts a human reviewed and ruled in Arcvue's favor
Bookkeeper aheadArcvue booked it; the legacy system has not. Excluded from the gate.
UnmeasuredNo verdict is possible yet. Counted honestly rather than as agreement.

Read "Unmeasured" carefully. It is not a synonym for zero and it is not agreement — it is the population Arcvue is declining to claim anything about.

Two tiles carry the agreement story:

  • Matched codings — found on both sides and paired, so they are comparable at all. This is the denominator everything else is read against.
  • Accepted differences (Arcvue right) — matched conflicts where an operator adjudicated that Arcvue coded it correctly and the legacy system did not.

Accepted differences (Arcvue right) counts as AGREED for cutover, and that is the point. Arcvue being ahead of the incumbent is a correct outcome, not a deficit. A difference is only a problem when Arcvue is wrong or absent — when Arcvue is right, the adjudication records that and the number stops arguing with you.

The legacy system's side, split three ways​

  • Persistent feed gaps (must fix) — the only category that fails the gate. This is your action list.
  • Transient gaps — timing, expected to resolve on their own.
  • Excused, itemized by reason: manual journal entries, system allocations, revenue recognition, billing, cost posts, expense settlements, intercompany, internal reclasses. Each has a stated reason — a cost post with no independent bank, card or email source event has nothing for Arcvue to have seen, so expecting it to appear would be expecting invention.

Eight tiles on the legacy side are excused — differences the verdict deliberately ignores because there is nothing for Arcvue to book, or because Arcvue already produces the same effect by another route:

BucketWhy it is excused
Manual JEs (excused)Hand-keyed entries. There is no source event to reproduce.
System allocations (excused — D2)Cost-pool rate postings, which Arcvue produces itself through allocation.
Revenue recognition (excused — D1)Arcvue reproduces it — the deferred-to-unbilled step. Coverage-guarded.
Billing (excused — D1)Arcvue reproduces it — the unbilled-to-billed sweep. Coverage-guarded.
Cost posts (excused)Expense-module labor and expense-report cost posts, plus clearing-cycle vouchers.
Expense settlements (excused)The payment tail of the expense-report cycle; its one bank event is already coded.
Intercompany (excused)Due-from / due-to entity moves with no cash leg.
Internal reclasses (excused)Balance-sheet-only reclasses — every leg a liability, no source event.

"Excused" means the DIFFERENCE is expected, never that the WORKFLOW is optional. Two of these say Arcvue reproduces it, and those are coverage-guarded — the excusal holds only while Arcvue is actually producing the equivalent. If Arcvue would do this natively after cutover, it has to work now, and an excusal that quietly stopped being earned is exactly the kind of missing rail this screen exists to surface.

Click any bucket to see the rows behind it. An excused tile that is growing is worth reading even though it does not move the verdict.

Every number drills through​

There are no dead-end aggregates. If a tile says 14, you can open the 14 and read them. Use that: judging a conflict from a tile is how a real defect gets mistaken for a rounding difference.

The drill tables vary by what you clicked, but the columns are consistent:

ColumnWhat it holds
Txn dateThe transaction date.
AgeHow long it has been sitting.
DocumentThe source document.
CounterpartyWho it was with.
Counterparty / DocBoth together, where the view is tight for space.
AmountThe value, right-aligned.

The narrow first column of the document table has no heading — it is the row expander, announced to screen readers as expand.

Part 3 — The actions​

Run Now re-grades. Use it after a fix rather than waiting for the scheduled pass.

Accept: Arcvue right records a human ruling that Arcvue was right and the answer key was wrong. It is an additive overlay on the read side — it never rewrites the underlying grade, so the original disagreement stays visible and auditable. Undo reverses it (its tooltip reads "Retract — return this item to the conflict count"). This is the honest way to handle a conflict where the legacy system is the one at fault, and it is the only sanctioned way to move the number without changing a coding. Note this is also the adjustment that separates the raw agreement rate from the effective one the gate reads.

TB tie-out checks that the trial balance agrees. That is a different and stronger claim than per-transaction agreement, and it is the leg worth the most attention — but it does not block promotion, and neither does any other leg. The legs describe the books; they do not grant or withhold permission.

Promotion (per segment) promotes one segment to system of record. The button reads Initiate Cutover and is offered for any segment that is not already promoted — readiness does not gate it. Cutover is a decision a person makes with the evidence in front of them, and the readiness panel above is that evidence: its chip reads ALL LEGS PASS or LEGS OUTSTANDING, which describes the books rather than granting permission.

Initiating cutover asks for two things, and both are deliberate:

  • Authoritative from — the period the spine becomes system of record, as YYYY-MM. This is the decision: it is the first month Arcvue owns, and every month before it stays on the legacy mirror, unaltered.

    The screen refuses three kinds of answer, and only the first two are obvious. A period that is not YYYY-MM is rejected on shape. A month that is already closed is rejected because nothing can be posted into it, so the opening balances would have nowhere to go.

    And the third: the month your opening balances were booked into is also refused. The boundary must be strictly after it — name the month after the OPENING BATCH.

    This is the one worth slowing down for, because "still open" does not protect you from it: the opening-balance month is open on the day you type it. If the boundary sits at that month, the opening entries stop being opening balances and start counting as postings — and the damage does not appear now. Every backfill into that month begins failing the moment the month closes, weeks after cutover, when nobody is looking at this screen any more. Naming the month after the opening batch keeps the batch below the boundary, where it stays a balance rather than a posting no matter how many times that month is later closed and reopened.

  • The confirmation phrase, typed exactly. Deliberately not a single click.

The promotion records who did it, when, the period named, and the readiness legs as they stood at that moment — so there is a permanent record of what the evidence said when somebody decided, whatever it said.

A Cutover readiness banner sits above everything and states whether a segment is clear to cut over.

Initiating a cutover opens a confirmation modal that requires you to type a phrase, and Cancel backs out of it. The typed phrase is deliberate friction. Cutover changes which system is authoritative for a segment, and a control that can be triggered by one misplaced click is the wrong shape for that decision.

Part 4 — How to actually work it​

  1. Read the streak, not today's percentage. One good day means very little; the gate is a consistency test.
  2. Work persistent feed gaps first. They are the only thing that fails the gate, and each one is a missing rail rather than a rounding difference — some path that should exist and does not.
  3. Then work conflicts, by drilling in. Each is either a real Arcvue defect or a case where Arcvue was right. Decide with evidence and use Accept difference for the latter.
  4. Never close a conflict by copying the answer key. See Part 1.

Part 5 — When something looks wrong​

"Agreement is above 95% but the gate is red." Almost always a persistent feed gap. Both conditions must hold; the tile that fails is the one to open.

"The streak reset and nothing changed." Either a newly-appeared persistent gap, or the percentage dipped below the bar for a single day. Drill that day's gap list.

"A tile reads zero and I don't believe it." Check the filters — they apply to the roll-up too, not just the drill-throughs — and check whether the population is Unmeasured rather than genuinely zero.

"The header says it is grading full history." No parallel-run start date is set, so every transaction ever is in scope. Honest, but usually not what you want to steer by.

"Promotion is disabled." The gate has not held for the required run of days. The button label names which condition is unmet.

One-line summary​

Parallel Run measures whether Arcvue, coding independently, reaches the same answer as the legacy system. Promotion needs three legs at once — 95% 30-day agreement on matched items, zero persistent feed gaps, and a passing trial-balance tie-out — measured over a rolling 30-day window rather than an unbroken streak. Work the feed gaps first, drill into conflicts rather than judging from tiles, use Accept: Arcvue right when Arcvue was right, and never make the number better by copying the answer key.