Square × Metabase

How to build Square sales dashboards in Metabase

Square processes your in-person and online payments and holds your orders, catalog, and payouts. Metabase is where you turn that sales activity into shared dashboards for revenue, products, refunds, and settlement. Because Metabase reads from SQL databases, the reliable way to connect them is a small pipeline: sync Square into a database or warehouse on a schedule, then point Metabase at it. This guide walks through that path end to end — including a free option with no paid connector.

Heads up: Metabase connects to SQL databases and warehouses — it does not ship a native Square connector. For dashboards that need history, sync Square (via its APIs or a managed connector) into a database first.

How do you connect Square to Metabase?

Metabase connects to SQL databases and warehouses — not to SaaS APIs directly, and there's no native Square connector. So connecting Square to Metabase means one thing: run a small pipeline that copies Square data into a database on a schedule, then connect Metabase to that database. Once the data lands, the models, metrics, and SQL later in this guide all work.

The good news: this doesn't require a paid tool. Use a managed connector if you want zero maintenance, or a free, code-based sync you host yourself — both are covered in Build the pipeline below, and in more depth in our guide to building a data pipeline.

What can you analyze from Square data in Metabase?

  • Gross and net sales — revenue before and after fees
  • Products and catalog — top items, categories, and units sold
  • Locations — performance across stores and registers
  • Refunds and disputes — refund rate, chargebacks, and reasons
  • Fees — processing cost as a share of sales
  • Payouts — settlement timing and net deposits

Which Square dashboards should you build in Metabase?

For: Founders, finance

Sales & net revenue

Gross sales and what lands after fees and refunds.

  • Gross sales by day (line)
  • Net sales after fees and refunds (line)
  • Average order value (number)
  • Sales by location (bar)
For: Ops, retail

Products & catalog

What sells and where.

  • Top items and categories by revenue (bar)
  • Units sold by item (table)
  • Sales by hour and day-of-week (heatmap)
  • Discounts applied and their impact (table)
For: Finance, ops

Refunds & disputes

Where money leaks back out.

  • Refund rate and refunded amount (number + line)
  • Disputes/chargebacks by month (bar)
  • Refund reasons (bar)
  • Payment success rate (line)
For: Finance, leadership

Fees & payouts

Cost of processing and cash landing in your account.

  • Processing fees as a share of sales (line)
  • Payouts and settlement timing (table)
  • Net settlement by month (number)
  • Tips and taxes collected (table)

How do you build the Square → Metabase pipeline?

For dashboards that need history and reliability, land Square data in a database first, then connect Metabase to that database.

No paid tool required. A fully free stack: a small dlt or hand-written script (extract) → a free Postgres database like Neon or Supabase (load) → a scheduler such as GitHub Actions cron (host) → Metabase (visualize). For hosting and scheduling details, see our data pipeline guide.

Connector options

  • Square APIs (free, first-party) — Payments, Orders, Catalog, and Payouts APIs into your own pipeline.
  • Airbyte — has a Square source covering payments, orders, and more. Free if you self-host the open-source version; paid on Airbyte Cloud.
  • Fivetran (paid, managed) — a Square connector with a maintained schema and incremental syncs.

Notes

  • Land raw tables first, then build clean models on top.
  • Amounts are in the smallest currency unit — divide in a model layer.
  • Separate processing fees and refunds so net sales are accurate.
  • Keep location_id on every fact so multi-location comparison is easy.

Can you generate a Square dashboard with AI?

Yes — and once Square data is synced into a database, this is the fastest way to a strong first draft. First give an AI assistant a way to read your Metabase schema and create questions and dashboards, then paste the prompt below. It builds the dashboard from your database tables and tells the agent to skip metrics the schema can't support instead of faking them.

Two ways to let an assistant query and build in Metabase

Both connect to a Metabase instance that's already pointed at your synced database — the pipeline above moves the data; these just let the assistant read and write Metabase. Pick whichever fits your setup:

Metabase MCP

Best for
Chat clients (Claude, Cursor, Codex)
Enable
Admin → AI → MCP
Endpoint
https://<your-metabase>/api/metabase-mcp
Auth
OAuth handled by Metabase

Metabase CLI

Best for
Terminal agents, scripts, and CI
Install
npm install -g @metabase/cli
Auth
Browser OAuth (v62+) or an API key
Docs
@metabase/cli

Set up the Metabase MCP server

Enable it under Admin → AI → MCP, then point your client at the endpoint:

ClaudeClaude Code CLI
# Metabase built-in MCP (replace with your instance URL)
claude mcp add --transport http metabase https://your-metabase.example.com/api/metabase-mcp
Cursor~/.cursor/mcp.json or .cursor/mcp.json
{
  "mcpServers": {
    "metabase": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://your-metabase.example.com/api/metabase-mcp"]
    }
  }
}

Clients with native remote support can use a "url" field instead of the mcp-remote bridge. Confirm the current endpoint in the Metabase MCP docs.

Set up the Metabase CLI

Install it globally, then authenticate once (the binary is mb):

Install & authenticateshell
# Install the CLI (the binary is `mb`)
npm install -g @metabase/cli

# Authenticate once — opens your browser on Metabase v62+, or use an API key
mb auth login --url https://your-metabase.example.com
mb auth status

On Metabase v62+ mb auth login opens your browser; older servers fall back to an API key. A terminal-based assistant can then inspect your schema (mb db schemas, mb table get --include fields) and create content (mb card create, mb dashboard create) against the synced tables.

Prompt: build the Square Sales Overview dashboard

With MCP or the CLI connected, paste this into your assistant to generate the dashboard:

Prompt for creating a Square Sales Overview dashboard
Create a polished Metabase dashboard for Square payments and sales analytics
using the available Square tables in this database.

Goal: Help founders and finance leaders understand gross and net sales,
products, refunds, disputes, fees, and payouts from Square data.

First, inspect the schema and identify the available Square tables. Do not assume
exact table names. Map the raw data into these analytical concepts where
possible: Payments, Orders, Order line items, Catalog items, Customers, Refunds,
Disputes, Locations, and Payouts.

Important:
- Build the dashboard from durable database/warehouse tables (Square APIs or a
  managed connector).
- Separate gross sales from net (after Square processing fees and refunds).
- Compute payment success rate on a consistent denominator.
- Handle multi-location data: allow filtering and comparison by location.
- Keep tips and taxes separate from product revenue.
- Do not claim Metabase connects natively to Square unless that is explicitly
  true in this environment.

Dashboard title: Square Sales Overview

Sections:
1. Executive summary (KPI cards): Gross sales; Net sales; Fees %; Refund rate;
   Average order value; Payments success rate.
2. Sales & net revenue: Gross sales by day; Gross vs. net; Sales by location.
3. Products & catalog: Top items/categories; Units sold; Sales by hour/day.
4. Refunds & disputes: Refund rate; Disputes by month; Refund reasons.
5. Fees & payouts: Fees as a share of sales; Payouts and settlement timing; Net
   settlement.

Filters: Location, Item/category, Payment method, Date range.

Before finalizing, create or recommend reusable Metabase models:
modeled_square_payments, modeled_square_orders, and modeled_square_refunds.

Output: Build the dashboard if you have permission; otherwise provide the exact
questions, SQL, model definitions, and layout. Include caveats for any metric
that cannot be calculated from the available schema. Reconcile totals against
Square Dashboard. Keep it practical, dense, and executive-readable. Avoid vanity
metrics.

How should you model Square data in Metabase?

Core tables

ConceptGrainKey columns
paymentsone row per paymentid, order_id, location_id, amount_money, processing_fee, refunded_amount, status, created_at
ordersone row per orderid, location_id, total_money, total_tax, total_tip, created_at
order_line_itemsone row per lineorder_id, catalog_object_id, quantity, gross_sales
refundsone row per refundid, payment_id, amount_money, reason, created_at
payoutsone row per payoutid, location_id, amount_money, status, arrival_date
locationsone row per locationid, name, currency, country

Modeling advice

  • Build a modeled_square_payments view with gross, fee, refund, and net per payment.
  • Keep tips and taxes in separate columns from product revenue.
  • Join line items to catalog for item- and category-level analysis.
  • Carry location_id everywhere for store comparison.
  • Reconcile modeled sales and payouts against Square Dashboard.

Which Square metrics should you track in Metabase?

MetricDefinitionNotes
Gross salesSum of completed payment amounts.Before fees and refunds.
Net salesGross − fees − refunds.What the business keeps.
Average order valueSales ÷ order count.Trend by location and daypart.
Refund rateRefunded ÷ completed payments.By count or amount — label which.
Fee rateProcessing fees ÷ gross sales.Watch by payment method.
Dispute rateDisputes ÷ payments.High rates risk penalties.

What SQL powers Square dashboards in Metabase?

These assume the modeled tables above (PostgreSQL dialect, amounts in minor units). Adjust identifiers to match your schema.

Daily sales, fees, and netPostgreSQL

Gross sales and what lands after Square processing fees.

SELECT
  date_trunc('day', created_at)                       AS day,
  COUNT(*)                                            AS payments,
  ROUND(SUM(amount_money) / 100.0, 2)                 AS gross_sales,
  ROUND(SUM(processing_fee) / 100.0, 2)               AS fees,
  ROUND(SUM(amount_money - processing_fee) / 100.0, 2) AS net_sales
FROM payments
WHERE status = 'COMPLETED'
  AND created_at >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY 1
ORDER BY 1;
Sales by locationPostgreSQL

Compare stores and registers on volume and average order value.

SELECT
  l.name                                      AS location,
  COUNT(*)                                    AS orders,
  ROUND(SUM(p.amount_money) / 100.0, 2)       AS gross_sales,
  ROUND(AVG(p.amount_money) / 100.0, 2)       AS avg_order_value
FROM payments p
JOIN locations l ON l.id = p.location_id
WHERE p.status = 'COMPLETED'
GROUP BY l.name
ORDER BY gross_sales DESC;
Refunds by monthPostgreSQL

Refunded payments and the amount returned.

SELECT
  date_trunc('month', created_at)                     AS month,
  COUNT(*) FILTER (WHERE status = 'COMPLETED')        AS payments,
  COUNT(*) FILTER (WHERE refunded_amount > 0)         AS refunded_payments,
  ROUND(SUM(refunded_amount) / 100.0, 2)              AS refunded_amount
FROM payments
GROUP BY 1
ORDER BY 1;

What are common mistakes when analyzing Square in Metabase?

Running dashboards off a one-time CSV export.→ Schedule the sync so data stays fresh — a manual export goes stale the moment someone acts on it.
Reporting gross without fees and refunds.→ Subtract processing fees and refunds to see the net the business keeps.
Blending tips and taxes into revenue.→ Keep tips and taxes in separate lines — they aren't product revenue.
Ignoring location.→ Multi-location businesses need location on every fact, or store comparisons are impossible.
Never reconciling with Square Dashboard.→ Sanity-check modeled sales and payouts against Square's own reports before trusting them.

Related analytics

Related metrics

Related integrations

FAQ

Does Metabase connect natively to Square?
No. Metabase reads SQL databases and warehouses. Sync Square into a database first (its APIs, Airbyte, or Fivetran), then connect Metabase to that database.
How do I compare locations?
Keep location_id on every payment and order, join to a locations table for names, and add a Location filter to your dashboard so you can slice or compare stores.
How do I get net sales, not just gross?
Model gross, processing fees, and refunds per payment, then net = gross − fees − refunds. Keep tips and taxes separate so they don't inflate product revenue.