---
type: entity
title: Squire
aliases:
  - Squire & Company
  - Squire Advisory
  - Squire Technology
modified: 2026-04-07
tags:
  - squire
  - target-customer
  - adoption-case
category: organization
---

# Squire

> The 50-year-old CPA firm and its integration-technology sister company — the target customer for SuiteCentral 2.0 adoption.

## What it is

Squire is the entire reason this wiki exists. The intended customer for SuiteCentral 2.0 is the executive leadership audience this wiki is written to convince.

## Corporate structure (resolved 2026-04-07)

Three related names that appear in source material refer to **three distinct things in a parent → division → sister company chain**:

| Name | What it is |
|---|---|
| **Squire & Company** | The 50-year-old parent CPA firm |
| **Squire Advisory** | An advisory *division* within Squire & Company |
| **Squire Technology** | A *sister company* spun out of Squire Advisory specifically to handle integration technology |

So when [[sources/01-executive-summary]] slide 1 says "an enterprise integration platform built for Squire Advisory," that's accurate at the broader/parent-practice level. When `CLAUDE.md` and the notebook query response say "Squire Technology Leadership," that's the specific integration-technology sister company that would be the operational customer.

**For the wiki's adoption framing**:
- The **operational customer** of SuiteCentral 2.0 is **Squire Technology** (the integration-tech sister company)
- The **strategic sponsor / advisory framing** is **Squire Advisory** (the parent division)
- The **enterprise umbrella** is **Squire & Company** (the parent CPA firm)
- The **direct decision-makers** are [[pages/entities/jonyce-bullock|Jonyce Bullock]] (CEO of Squire & Company) and [[pages/entities/reuben-cook|Reuben Cook]] (President of Squire Technology). **Confirmed from [[sources/read-talking-points]] 2026-04-07** — previously only known from notebook query results / project memory.

Future ingests may justify splitting this page into three separate entity pages (`squire-and-company`, `squire-advisory`, `squire-technology`) as more specific claims attach to each. For now, all three are aliases of this umbrella page.

## Why it matters (to the adoption case)

Squire is the *audience* — every page in this wiki is written for them. Per the notebook's audience instruction (which the user typed directly into NotebookLM):

> "Audience: Squire Technology Leadership. Tone: Engaging, Informational, Encouraging without overly selling. Goal is to help them see why this is a product they would want to upgrade/adopt and worth looking into."

## Current state (per [[sources/01-executive-summary]] slide 6)

- Fragmented workflows
- Duplicated overhead
- **Runs SuiteCentral 1.0** as the current production platform (per [[sources/read-elevator-pitch]] Beat 4: *"built on the credibility of SuiteCentral 1.0"*). This is the first formally-ingested confirmation that SC 1.0 is Squire's current baseline, and that the adoption case is specifically about moving from 1.0 to 2.0 — not adopting a platform from scratch.
- **Does NOT yet run SuiteCentral 2.0 in production** (per [[sources/read-elevator-pitch]] Beat 4: *"SuiteCentral 2.0 is production-ready, but not yet deployed in Squire production"*). SC 2.0 is production-ready code that has not been turned on in Squire's environment.

## Historical baseline (per [[sources/read-elevator-pitch]] Beat 1)

Squire's adoption case has a concrete temporal arc:

> "Three years ago our problem was manual mapping, with about 15 hours of labor per integration. Today the problem is survival."

- **~2023 baseline**: ~15 labor-hours per integration, via manual mapping. This is what SuiteCentral 1.0 presumably improved on to earn the "credibility" foundation for 2.0.
- **~2026 (today)**: the problem is no longer labor efficiency — it is market survival. Oracle and Microsoft are shipping native AI + MCP capabilities, and "last week's 'Something Big is Happening' narrative made this a board-level concern." The failure mode the adoption case is defending against: *"If we remain a services-heavy connector model, we get commoditized on both speed and value."*

This gives the adoption case a clean three-point arc: manual (2023) → efficient (SuiteCentral 1.0) → survival-grade governance (SuiteCentral 2.0). The HintonBurdick acquisition compounds the urgency — it is not just about market survival but about making the acquired client base economically work.

## Target state (per same source)

- Unified platform
- Governed operations

## Outcome promise

- Faster delivery
- Stronger audit posture

## The business-model transformation thesis (per [[sources/ai-governance-layer-video]] 00:07-00:13)

> "This platform transforms Squire from an integration provider to a platform leader who governs integrations."

This is the deepest strategic framing in the corpus. The SuiteCentral 2.0 adoption case is not about tool upgrade — it is about Squire's business-model evolution from *services* (selling consulting hours) to *platform* (selling a governed AI integration layer that other customers can license). This is consistent with:

- Jonyce Bullock's (CEO) "recurring revenue potential — SaaS licensing for SuiteCentral platform" angle in [[sources/read-talking-points]]
- The "60+ customers in year 1" scale target in [[sources/ai-governance-layer-video]] and captured on [[pages/concepts/pilot-30-60-90]]
- The elevator pitch's commoditization-risk framing in [[sources/read-elevator-pitch]]: *"If we remain a services-heavy connector model, we get commoditized on both speed and value."*

The HintonBurdick acquisition forces the transformation (you can't scale consulting hours linearly with 2× clients), and the market window for establishing a governance-layer moat is 6-12 months (per the video). The thesis is: **Squire has to become a platform company now, or get commoditized by Oracle/OpenAI/Microsoft later**.

## Single codebase unifies distinct consulting practices (per [[sources/ai-governance-layer-video]] 02:28-02:40)

> "We unify Squire's distinct consulting practices with a single code base. This enables cross-selling and maintains a single standard of excellence, unlike platform vendors optimized for only one ERP."

Important operational implication: Squire has **multiple distinct consulting practices** (likely NetSuite-focused practice and a Business-Central-focused practice — and, post-[[pages/entities/hintonburdick|HintonBurdick]] acquisition, any new verticals from HintonBurdick's client base). The dual-ERP architecture of SuiteCentral 2.0 is what lets a single code base serve all these practices, enabling cross-selling between them and preventing practice-level silos.

## The business pressure behind the adoption case (per [[sources/read-talking-points]])

Squire's adoption case is not driven by vague "fragmentation" — it is driven by a specific, recent operational crisis:

> "We just acquired a firm that doubled our client base across new verticals. Manual consulting doesn't scale. AI governance does."
> — [[sources/read-talking-points]] talking point #6, "The HintonBurdick angle"

Squire recently acquired [[pages/entities/hintonburdick|HintonBurdick]], a firm that **doubled its client base** and added **new verticals**. The combined entity now has roughly 2× the clients it had before the acquisition, and the existing "manual consulting" delivery model cannot physically scale to serve that volume without linear cost growth (2× consultants).

This converts the SuiteCentral 2.0 pitch from a nice-to-have unification project into a **growth-enablement requirement**:
- Manual consulting scales linearly with client count → doubling clients doubles cost → the acquisition is financially dilutive without automation
- AI automation with governance scales sub-linearly → doubling clients can be absorbed with a much smaller headcount increase → the acquisition becomes accretive
- Therefore SuiteCentral 2.0 is what makes the HintonBurdick acquisition economically work

The [[pages/entities/jonyce-bullock|CEO soundbite]] — **"Scale 10x clients without 10x consultants"** — is directly about this.

The existing "Two-Platform Problem" framing (still not explicitly in an ingested source) is likely a downstream consequence: if HintonBurdick runs on a different ERP than Squire (plausibly Business Central, given SuiteCentral 2.0's emphasis on the dual-ERP NetSuite-AND-Business-Central story), then the combined entity runs on two ERPs simultaneously. Flagged for verification when a source explicitly describes the Two-Platform Problem.

## Squire's two separate practices (per [[sources/business-case]])

Squire currently operates **two separate integration practices** with no cross-selling:

1. **NetSuite Practice** (SuiteCentral 1.0): NS-only integrations, manual field mapping (15 hours per integration), limited to CRM/eCommerce targets, no AI
2. **Business Central Practice**: separate toolset, no AI capabilities, cannot leverage SuiteCentral infrastructure, custom development per project

**Impact**: 2× operational overhead (two platforms to maintain), 225+ hours wasted annually per consultant on manual mapping, cannot cross-sell between practices. SuiteCentral 2.0 unifies both under a single AI-powered platform.

## 40+ client environments — CONFIRMED (per [[sources/business-case]])

*"SuiteCentral 1.0 already supports Squire delivery across 40+ client environments"* — this was previously known from notebook queries and now formally ingested from the v4.1 business case (dated April 9, 2026). The 40+ number is the baseline that de-risks the SuiteCentral 2.0 pilot: it's building on proven 1.0 credibility, not starting from scratch.

## Andy's 3 Questions — the deployment decision (per [[sources/april-2026-refresh-batch]])

A Squire executive named Andy asked three specific questions. The April 2026 Leadership Brief answers them directly:

| Question | Answer |
|---|---|
| **"Is it a standalone product?"** | *"It can be."* — runs independently with its own dashboard, AI engine, 16-module library, connector framework. Connects to both ERPs. Does NOT depend on SuiteCentral 1.0. |
| **"Can Squire incorporate it into existing SuiteCentral products?"** | *"Also yes."* — designed as the AI upgrade path for PaymentCentral, VendorCentral, SyncCentral, and the other modules Squire already sells to 40+ clients. Adds AI field mapping, governance, reasoning traces, dual-ERP. |
| **"What is the end goal?"** | *"Keep Squire competitive and ahead of the market."* — Oracle, Celigo, and Workato have all shipped AI. SuiteCentral 2.0 gives Squire a platform it OWNS with governance capabilities none of them have. |

**Key takeaway**: the architecture supports BOTH paths — standalone or integrated. **Deployment strategy is Squire's decision.** This means Squire's leadership doesn't have to choose up front; they can pilot as standalone, then decide whether to integrate into existing products based on pilot results.

## The commercialization endgame

Per [[sources/business-case]]: SuiteCentral 2.0 can be evaluated as a **strategic platform acquisition/license candidate** (per [[sources/24-strategic-acquisition]]) with three revenue channels targeting **$4.4M-$7.4M Year 3 ARR** and a **$35M-$89M platform valuation** at 8-12× ARR. See [[pages/concepts/revenue-model]] for the full financial architecture.

The go-to-market positioning tagline: **"The platform NetSuite consultants use themselves."**

## Open questions
- ~~Two-Platform Problem~~ **RESOLVED**: [[sources/01-vision-document]] uses the explicit heading *"Squire's Specific Pain: The Two-Platform Problem"*. Both the name and the substance (two practices, 2× overhead, zero cross-sell) are now formally confirmed from the vision document (April 9, 2026) and the business case.
- HintonBurdick's practice area, ERP platform, and acquisition date are still unknown — see the open questions on [[pages/entities/hintonburdick]].

## Sources

- [[sources/01-executive-summary]] — claims 1, 9, 10, 11 (identity, current state, target state, outcome promise)
- [[sources/read-talking-points]] — claims 1, 9, 12 (named decision-makers, HintonBurdick acquisition, CEO growth angle)
- [[sources/read-elevator-pitch]] — claims 1, 2, 3, 13, 14 (historical baseline ~15 labor-hours/integration, survival-grade market pressure, commoditization risk, SC 2.0 not yet deployed in Squire, SC 1.0 as credibility baseline)
- [[sources/ai-governance-layer-video]] — claims 2, 17 (business-model transformation from integration provider to platform leader; single-codebase unification of distinct consulting practices)