Skip to main content
Share / Export

Stage 7: Beginning Balance Decisions

Decide which beginning-balance core objects are in scope and, for each, the load depth (Not Applicable, summary, detail, month-by-month variants). These decisions feed Go-Live execution and Company Tracker visibility. Frame the stage as scope and depth decisions, not as a load rehearsal.

phase_key: practice_balance_loads

What this stage accomplishes​

  • The team agrees which of the twelve core objects apply for this company (client deselects what does not apply).
  • For each in-scope object, load depth is chosen (for example go-live month summary vs detail, or month-by-month packaging).
  • Historical depth and conversion boundaries are explicit: what is a beginning-balance load versus what starts to look like paid data conversion.
  • Company Tracker reflects the balance-related work that remains relevant (sync and refresh, same pattern as other stages).
  • Selections here populate the Stage 9 Go-Live execution board.

Typical work / artifacts​

  • Decision record for in-scope core objects
  • Per-object depth choices (summary / detail / month-by-month / Not Applicable as offered)
  • Notes on historical boundary and whether any path leans conversion rather than a simple beginning-balance load
  • Company Tracker visibility aligned to the balance-related actions that still apply

Item-level option labels, defaults, and estimates: Beginning balance item options reference.

Core objects (product list)​

Choose what pertains to this company. Example: no Service means deselect Service Work Orders.

  1. CM Accounts
  2. Contracts
  3. Customers
  4. Employees
  5. Equipment
  6. GL Accounts
  7. Inventory
  8. Jobs
  9. Purchase Orders
  10. Service Work Orders
  11. Subcontracts
  12. Vendors

The product may sort alphabetically in the UI. Docs list the twelve explicitly; either order is fine as long as all twelve are present.

Per-object options pattern (example: Jobs)​

When Jobs is in scope, the company typically needs at least open jobs for the year. Job cost (and similar areas) usually offer packaging choices such as:

  • Not applicable
  • As of go-live month: summary
  • As of go-live month: detail
  • Month-by-month summary
  • Month-by-month detail

Same underlying data; different packaging and batch shapes. Other core objects follow the same idea with their own item lists (see the options reference).

Summary vs detail (major highlight)​

The primary difference between summary and detail is time and effort (batch count), not a different truth.

Example: three years of monthly job costs can mean 30+ Vista batches. Year-end summary plus the go-live month is closer to about 4 batches. Secondary question: do users need detail available later, or is summary enough for how they will operate after go-live?

Defaults in the product skew toward prerequisite master loads, summary / remaining-balance styles for history, and Not Applicable for items such as Projected Cost, JB Progress Billings, and PO / SL change orders unless the client selects them.

Historical depth and the conversion boundary​

"Seven years of history" must be defined. Every historical job? Job cost detail for all of them? Fully linked downstream history?

Fully linked AP invoice detail with source, plus billing with exact cash receipts, starts to look like a data conversion path, not a simple beginning-balance load. Call that boundary early so the plan stays honest about effort and ownership.

Beginning-balance load vs data conversion​

  • Beginning-balance load: the user or consultant loads balances into Vista under the depth choices made here.
  • Data conversion: a paid extract / transform / load from the current ERP into Vista in a more controlled structure.

Conversion does not remove client work. Respectable vendors still require multiple reloads and client validation. It changes who pushes data in, not whether the client spends time confirming it.

Opinionated guidance​

Full conversion is rarely needed when the client can still access old data (for example an Excel export used as a lookup). The case is stronger when the prior system is cloud-hosted with no database access. Field experience: clients rarely regret skipping a large conversion fee when lookup access to the old system (or exports) remains available.

Keep this stage on decisions. Load how-tos and Vista procedures live elsewhere (Tracker / Implementation Balance articles and the TUDS Stage 7 how-to).

Connection to Company Tracker / Vista​

Same pattern as other stages: selections and items sync to Company Tracker; use sync and refresh so Playbook and Tracker stay aligned. Actual Vista balance work follows these decisions during Go-Live. The Stage 9 execution board stays empty until Stage 7 is finalized.

Exit / moves to next stage​

Beginning Balance Decisions is complete when in-scope core objects, load depth, and historical / conversion boundaries are finalized, and Tracker visibility is aligned. The implementation then moves to Cutover Readiness.

In the product​

In Mission Control, complete the Beginning Balance Decisions workspace (scope, depth, boundaries, and visibility sync). For step-by-step UI, see Complete the Beginning Balance Decisions Stage. For shell navigation and exports, see Run the Implementation Playbook.