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 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 Jonyce Bullock (CEO of Squire & Company) and Reuben Cook (President of Squire Technology). Confirmed from 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 01-executive-summary slide 6)

• Fragmented workflows
• Duplicated overhead
• Runs SuiteCentral 1.0 as the current production platform (per 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 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 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 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 read-talking-points
• The “60+ customers in year 1” scale target in ai-governance-layer-video and captured on pilot-30-60-90
• The elevator pitch’s commoditization-risk framing in 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 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-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 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.” — read-talking-points talking point #6, “The HintonBurdick angle”

Squire recently acquired 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 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 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 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 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 business-case: SuiteCentral 2.0 can be evaluated as a strategic platform acquisition/license candidate (per 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 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: 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 hintonburdick.

Sources

• 01-executive-summary — claims 1, 9, 10, 11 (identity, current state, target state, outcome promise)
• read-talking-points — claims 1, 9, 12 (named decision-makers, HintonBurdick acquisition, CEO growth angle)
• 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)
• ai-governance-layer-video — claims 2, 17 (business-model transformation from integration provider to platform leader; single-codebase unification of distinct consulting practices)