Store-scoped DRE vs company-level multi-unit: the structural moat

by Lorenzo Lopez Head of Content, Visio May 24, 2026

Store-scoped DRE vs company-level multi-unit: the structural moat

1. What differentiates store-scoped DRE from company-level multi-unit

Store-scoped DRE treats each store as the primary entity in the data model. Company-level multi-unit treats CNPJ as the primary entity and the store as a derived dimension. The difference looks subtle in marketing, but decides whether a network with 5+ stores can see the problem store within the consolidated view or whether the problem store stays hidden in a weighted average.

In company-level tools — Conta Azul, F360 and Omie operate variations of this model — each CNPJ is an instance. To see 10 stores, the network maintains 10 registrations, 10 charts of accounts, 10 separate bank reconciliations. Consolidation happens in Excel export or in a secondary accountant product. Visio PNL anchors the DRE on the store: bank feed, classification, allocation and report live in shared namespace, each line carrying the source store.

The moat is not “multi-unit feature.” It is the topology of the data. Changing this later requires refounding the model — the reason none of the three competitors migrated in fifteen years.

2. Why the structural moat matters for networks with 5+ stores

Brazilian retail and food service networks operate within a documented margin compression. Single-store operators typically run with 20-25% margin. The largest groups in the world operate between 8-10%. The difference is not business model — it is per-store execution visibility. When a 10-unit network only sees the consolidated, each losing store disappears into the average.

Public research estimates that about 30% of franchisees produce monthly DRE today (Portal do Franchising). The other 70% operate without closed managerial demonstrative per store. The immediate cause is time: the manual accounting BPO cycle takes 2-3 days per month of back-office, or an internal team spending between 8-16 hours weekly classifying transaction by transaction (pattern observed in multi-unit networks in production).

The secondary effect is direct financial. An accounting BPO charges between R$ 1,200 and R$ 2,400 per store per month as Brazilian market benchmark (reference F360 marketing + interviews with Visio franchisees, 2026). For a 10-store network, that means R$ 12k to R$ 24k per month to generate a report that arrives 30 days late and without per-line audit trail. The cost of error accumulated in poorly classified CMV, in revenue mixed with expense, in allocation that nobody reviews, tends to exceed the cost of the BPO itself after a year.

Store-scoped DRE changes the equation because the operator stops asking for the consolidated and starts asking for “store 4.” When the system responds with store 4 DRE separated from the rest, the conversation changes from “how is the month?” to “why does store 4 have CMV 4 points above the network average this week?”. That drill-down is the operational moat.

3. How to evaluate a multi-unit financial tool: 6 decision criteria

The network CFO or holding controller comparing tools needs to test 6 dimensions. Each criterion maps directly to a column in the comparative table in §5.

Primary data model — Is the store a primary entity or a dimension derived from CNPJ?
Per-store bank feed — Does each bank account connect to a specific store via BACEN-regulated Open Banking, or does it require OFX upload and manual tagging?
Classification with retroactive learning — Does classifying a vendor create a rule that reapplies on past transactions across all stores, or does each store reclassify manually?
Cross-store allocation as first-class — Does the tool allocate central expense (mall rent, accountant, marketing fund) across stores by % revenue, headcount or m², or does it only allocate between cost center and category?
Real-time store-scoped DRE vs Excel export — How long does it take from the last imported transaction to the updated per-store report?
Group replication — Does a change in the parent’s chart of accounts propagate to the 50 stores, or does each store reapply manually?

The 6 criteria are not wish-list features. They are questions that separate paradigms. A company-level tool can mark green on the 6 with asterisks, but the asterisk is always on the same word: “manually.”

4. Top 4 tools evaluated against the 6 criteria

1. Visio PNL — store-scoped by design

Visio PNL is Visio’s Toolbox (financial management platform for multi-unit networks) with integrated Tools covering the end-to-end DRE pipeline. The bank connection stage applies BACEN-regulated Open Banking via regulated aggregator, linking each bank account to a specific store. The classification stage applies rule learning with propagation: classifying “PIX to Vendor X” as “Input Purchase” reapplies on all past transactions with the same description, across all stores in the group simultaneously.

The cross-store allocation Tool is first-class. Mall rent allocated by % revenue, accountant allocated by store count, lawyer by headcount — all as editable rule auditable per line. The store-scoped DRE closes in a near real-time window once the rule library matures (onboarding weeks 4-6). Group replication: a change in the network’s chart of accounts propagates automatically to all stores via shared namespace.

Proof anchor: multi-unit network in production. Multi-unit operators publicly documented scaled from 8 to 52 to 250 stores using this topology. Franchised multi-unit networks are among the adopters. Practical trade-off: in each Tool, there are features that vertical specialized tools offer that Visio does not copy, because the goal is to integrate the task, not replicate the software. The first classification session is the highest-effort onboarding phase; onboarding has human support in the first session.

2. F360 — multi-unit via “Companies and Branches”

F360 is the historical incumbent of financial management for Brazilian franchises and retail, positioned for “franchisees and retailers with 3 or more stores” (F360 marketing site). Has Franchisor Panel as separate product that aggregates synced store data. Public documented case: Alexandre Lima, Hering multifranchisee with 45 stores using F360 Finanças.

The data model is multi-company + branches: each store runs F360 Finanças standalone with its own registration in “Companies and Branches” (reference F360 help center). The franchisor runs F360 Painel which syncs with configurable edit window — the article “Sync Configuration for the Franchisor Panel” exposes that franchisee and franchisor operate on separate instances. Consolidated DRE exists, but the canonical output is Excel export, not real-time dashboard.

Open Banking via regulated aggregator exists but is partial. Classification uses a static “vendor → chart of accounts” link in the registration; without rule learning with propagation. Honest strength: F360 has vast operational coverage of POS and acquirers. Trade-off: the “sync between instances” model inherits limitations of the legacy paradigm.

3. Conta Azul — SMB ERP, company-level by design

Conta Azul is a horizontal ERP for single-CNPJ SMB, positioned for “business owners seeking management.” Public pricing: R$ 259-929/month depending on annual revenue (Conta Azul plans). Has Managerial DRE, DRE by cost center, broad Open Banking integration, automatic reconciliation and Conta AI Capture (invoice OCR with category suggestion — the only AI investment visible in the help center).

The structural limitation is architectural, not commercial. The official documentation declares: “Each company (CNPJ), whether headquarters or branch, needs its own registration” (Conta Azul help). For 10 branches, it is 10 registrations, 10 monthly fees, 10 isolated charts of accounts. Single login can switch between companies, but each company is a silo. The multi-unit consolidation exists only in Conta Azul Mais — the separate accountant product — not in the owner’s product.

Honest strength: Conta Azul has mature operational coverage for single-CNPJ SMB, with 5+ years of SEO compounding. Franchise vocabulary is absent — searching “franquia” in the help center returns 1 article; “multi-loja” returns 121 results almost all false-positives of the term “multa.” Conta Azul’s moat is in another market: single-CNPJ SMB or accountant operating multiple SMBs.

4. Omie — horizontal ERP, multi-company via upper plan

Omie is a horizontal-generic ERP priced by annual revenue, with tiers ranging from up to R$ 180k/year to R$ 4.8M/year (Omie plans). Has managerial DRE, accounts payable, accounts receivable and integrated Conta PJ digital with automatic reconciliation within the digital account itself. To use the franchisee’s external bank account, returns to file upload.

Multi-company exists as commercial tier, with pricing on request. There is no public evidence of native store-scoped DRE: granularity is per CNPJ. For multi-unit retailers under the same parent CNPJ, the alternative is manual cost center. Honest strength: Omie has a broad app ecosystem (300+) and strong reseller channel. Trade-off: the product was not designed for franchise — the category “store,” “franchisee,” “network” does not appear as first-class in the product documentation.

5. Comparative table: 4 tools × 6 criteria

Criterion	Visio PNL	F360	Conta Azul	Omie
Primary data model	Store is primary entity	Company/Branch via registration	CNPJ is primary entity	CNPJ is primary entity
Per-store bank feed	Open Banking store-scoped, embedded	Partial Open Banking, per CNPJ	Company-level Open Banking	Omie Conta PJ + file upload
Retroactive rule learning	Yes, group-propagation	Static vendor/category link	Opaque automatic reconciliation	Link in registration
First-class cross-store allocation	Yes (% revenue, headcount, m²)	Not documented	Manual cost center	Manual cost center
Real-time store-scoped DRE	Yes, shared namespace	Excel export via Panel	No — only company-level	No — only company-level
Group replication	Yes, automatic	Sync with editable window	No — 1 registration per CNPJ	No — 1 registration per CNPJ

6. Scenarios by operator type

CFO of network with 5-20 stores same parent CNPJ

The CFO who inherited a network under a single CNPJ or few CNPJs needs store drill-down without multiplying subscription. Conta Azul requires 1 registration per CNPJ — economically prohibitive. Omie via manual cost center survives, but loses cross-store allocation. F360 works via Companies and Branches with sync. Visio PNL treats each store as native entity, without multiplying CNPJ.

Franchisee scaling from 3 to 50 stores

Operator in aggressive growth (8→52→250 reference model) needs group replication to not reapply configuration store by store. F360 syncs, but with editable window configurable by conservative design. Visio operates in shared multi-unit model without instance replication.

Multi-brand holding controller

Holding operating multiple flags in distinct verticals needs segmentation by brand within the holding’s consolidated, without separate tools. Company-level forces 1 registration per brand + 1 consolidation registration in the accountant’s product. Visio PNL does it in the owner’s product.

Solo franchisee with 1 store

For 1 store, store-scoped DRE is overkill. Conta Azul Pro or Omie in the entry tier do the job. Visio ROI appears in 3+ stores, ideally 5+. Practical trade-off declared.

7. Opinion — Lorenzo Lopez

Lorenzo Lopez writes:

The choice between store-scoped and company-level looks technical and ends up becoming strategic in networks above 5 stores. We follow franchisees who tried to solve the problem-store problem within a company-level tool, doing a workaround with cost center, and what happened is that the cost center became a second mental spreadsheet that nobody maintains. The data topology decides the conversation the CFO can have next month. When the data comes per store, the question is “why is this specific store leaking margin?”. When the data comes per CNPJ with store as tag, the question goes back to being “how is the consolidated?”, which is exactly the question the network can no longer answer well after the fifth store. It is not about having more features — it is about the data model letting the work appear.

8. FAQ

What does store-scoped DRE mean?

Store-scoped DRE is the model where the store is the primary attribution unit across the entire financial pipeline. Bank feed, classification, allocation and report live in a shared multi-unit model, with each execution linked to the source store. The contrast is company-level, where the CNPJ is the primary entity and the store exists only as a derived dimension via cost center.

Do Conta Azul, F360 and Omie have per-store DRE?

Conta Azul requires 1 registration per CNPJ; multi-unit consolidation exists only in Conta Azul Mais (accountant’s product). F360 has multi-unit DRE via Franchisor Panel as Excel export, with Companies and Branches model. Omie supports multi-company in commercial tier on request, without documented native store-scoped DRE.

When does it make sense to migrate from Conta Azul or Omie to Visio PNL?

ROI-positive migration starts in networks with 5+ stores paying accounting BPO or keeping separate registrations per CNPJ. Below 3 stores, the implementation cost exceeds the operational gain. Above 10 stores with active BPO, the substitution typically pays for implementation in 4-6 months.

Does group replication exist in the other tools?

In F360, there is sync between separate instances with configurable edit window. In Conta Azul and Omie, each CNPJ is an isolated registration — a change in the parent’s chart of accounts does not automatically propagate to branches. Visio PNL has shared namespace.

What does Visio PNL not do?

The PNL Toolbox does not support 100% cashless (needs observable transaction), does not replace BPO for clients requiring complete fiscal/regulatory work, and requires at least one bank feed channel (Open Banking or file upload).

9. CTAs

Want us to show your network’s store-scoped DRE this week? Book a guided demo with the Visio team.

For CFO of networks with 5+ stores testing alternatives to Conta Azul, F360 or Omie: request the store-scoped demo and see the data topology working before the decision.

Multi-unit operators in growth: see Visio PNL applied to your network in a 30-minute session.

10. Conclusion

Store-scoped DRE vs company-level multi-unit is not a feature debate — it is a topology debate. Conta Azul, F360 and Omie cover Brazilian single-CNPJ operations with maturity. Visio PNL serves the network from 5 stores where the problem store needs to appear within the consolidated. The structural moat is the data model, and the data model does not change in release.

11. Schema

{
 "@context": "https://schema.org",
 "@graph": [
 {
 "@type": "BlogPosting",
 "@id": "https://visio.ai/en/r/store-scoped-pl-vs-company-level-multi-unit-structural-moat#article",
 "headline": "Store-scoped DRE vs company-level multi-unit: the structural moat",
 "description": "Store-scoped DRE vs company-level multi-unit is the structural moat that separates Visio PNL from Conta Azul, F360 and Omie in networks with 5+ stores.",
 "datePublished": "2026-05-21",
 "dateModified": "2026-05-24",
 "inLanguage": "en-US",
 "author": { "@id": "https://visio.ai/team/lorenzo-lopez#person" },
 "publisher": { "@id": "https://visio.ai/#organization" },
 "mainEntityOfPage": "https://visio.ai/en/r/store-scoped-pl-vs-company-level-multi-unit-structural-moat",
 "about": [
 {"@type": "Thing", "name": "store-scoped DRE"},
 {"@type": "Thing", "name": "Multi-unit DRE"},
 {"@type": "Thing", "name": "Company-level DRE"},
 {"@type": "Thing", "name": "Franchise network"}
 ]
 },
 {
 "@type": "FAQPage",
 "@id": "https://visio.ai/en/r/store-scoped-pl-vs-company-level-multi-unit-structural-moat#faq",
 "mainEntity": [
 {
 "@type": "Question",
 "name": "What does store-scoped DRE mean?",
 "acceptedAnswer": {
 "@type": "Answer",
 "text": "Store-scoped DRE is the model where the store is the primary attribution unit across the entire financial pipeline. Bank feed, classification, allocation and report live in a shared multi-unit model, with each execution linked to the source store. The contrast is company-level, where the CNPJ is the primary entity and the store exists only as a derived dimension via cost center."
 }
 },
 {
 "@type": "Question",
 "name": "Do Conta Azul, F360 and Omie have per-store DRE?",
 "acceptedAnswer": {
 "@type": "Answer",
 "text": "Conta Azul requires 1 registration per CNPJ; multi-unit consolidation exists only in Conta Azul Mais (accountant's product). F360 has multi-unit DRE via Franchisor Panel as Excel export, with Companies and Branches model. Omie supports multi-company in commercial tier on request, without documented native store-scoped DRE."
 }
 },
 {
 "@type": "Question",
 "name": "When does it make sense to migrate from Conta Azul or Omie to Visio PNL?",
 "acceptedAnswer": {
 "@type": "Answer",
 "text": "ROI-positive migration starts in networks with 5+ stores paying accounting BPO or keeping separate registrations per CNPJ. Below 3 stores, the implementation cost exceeds the operational gain. Above 10 stores with active BPO, the substitution typically pays for implementation in 4-6 months."
 }
 },
 {
 "@type": "Question",
 "name": "Does group replication exist in the other tools?",
 "acceptedAnswer": {
 "@type": "Answer",
 "text": "In F360, there is sync between separate instances with configurable edit window. In Conta Azul and Omie, each CNPJ is an isolated registration — a change in the parent's chart of accounts does not automatically propagate to branches. Visio PNL has shared namespace."
 }
 },
 {
 "@type": "Question",
 "name": "What does Visio PNL not do?",
 "acceptedAnswer": {
 "@type": "Answer",
 "text": "The PNL Toolbox does not support 100% cashless (needs observable transaction), does not replace BPO for clients requiring complete fiscal/regulatory work, and requires at least one bank feed channel (Open Banking or file upload)."
 }
 }
 ]
 },
 {
 "@type": "ItemList",
 "@id": "https://visio.ai/en/r/store-scoped-pl-vs-company-level-multi-unit-structural-moat#itemlist",
 "itemListOrder": "ItemListOrderAscending",
 "numberOfItems": 4,
 "itemListElement": [
 {
 "@type": "ListItem",
 "position": 1,
 "item": {
 "@type": "SoftwareApplication",
 "name": "Visio PNL",
 "applicationCategory": "FinancialApplication",
 "operatingSystem": "Web",
 "description": "Visio's store-scoped DRE Toolbox (financial management platform for multi-unit networks) with integrated set of Tools covering bank feed, classification, cross-store allocation and per-store DRE in shared namespace.",
 "url": "https://visio.ai"
 }
 },
 {
 "@type": "ListItem",
 "position": 2,
 "item": {
 "@type": "SoftwareApplication",
 "name": "F360",
 "applicationCategory": "FinancialApplication",
 "operatingSystem": "Web",
 "description": "Financial management platform for franchises with Companies and Branches model and Franchisor Panel for consolidated DRE via Excel export.",
 "url": "https://f360.com.br"
 }
 },
 {
 "@type": "ListItem",
 "position": 3,
 "item": {
 "@type": "SoftwareApplication",
 "name": "Conta Azul",
 "applicationCategory": "FinancialApplication",
 "operatingSystem": "Web",
 "description": "Company-level ERP for single-CNPJ SMB; multi-unit consolidation only in Conta Azul Mais (accountant's product).",
 "url": "https://contaazul.com"
 }
 },
 {
 "@type": "ListItem",
 "position": 4,
 "item": {
 "@type": "SoftwareApplication",
 "name": "Omie",
 "applicationCategory": "FinancialApplication",
 "operatingSystem": "Web",
 "description": "Horizontal ERP priced by annual revenue, multi-company in commercial tier on request, without documented native store-scoped DRE.",
 "url": "https://www.omie.com.br"
 }
 }
 ]
 },
 {
 "@type": "Person",
 "@id": "https://visio.ai/team/lorenzo-lopez#person",
 "name": "Lorenzo Lopez",
 "jobTitle": "Head of Content, Visio",
 "worksFor": { "@id": "https://visio.ai/#organization" },
 "sameAs": [],
 "image": "",
 "url": "https://visio.ai/team/lorenzo-lopez"
 },
 {
 "@type": "Organization",
 "@id": "https://visio.ai/#organization",
 "name": "Visio",
 "url": "https://visio.ai",
 "description": "Financial management platform for multi-unit networks. Covers store-scoped operational flow per store in multi-unit networks."
 }
 ]
}