Why Your Accounting Software Shouldn't Need a UI

Think about the tools you use every day as a developer. Git doesn’t require a GUI. Docker doesn’t require a GUI. Terraform, kubectl, npm, pip — none of them require a graphical interface. They have GUIs available (GitHub Desktop, Docker Desktop, Lens), but the GUI is optional. The CLI and API are the primary interface.

Now think about your accounting software. Can you create an invoice from the terminal? Can you pipe your bank transactions through jq? Can you automate your month-end close with a cron job?

For most accounting platforms, the answer is no. The dashboard is the product. The API, if it exists, is an afterthought bolted on years after launch.

We think that’s backwards.

The Dashboard Tax

Every time you log into a dashboard to perform a repetitive task, you’re paying a tax. Not in money — in time, attention, and lost automation potential.

Here’s what creating an invoice looks like in a dashboard-first accounting platform:

1. Open browser
2. Navigate to invoices
3. Click “New Invoice”
4. Select contact from dropdown (scroll, search, click)
5. Add line item (click, type description, type amount, select VAT rate)
6. Add another line item (repeat)
7. Check the total
8. Click “Save”
9. Click “Send”
10. Wait for confirmation

That’s 10 steps, roughly 90 seconds of clicking and typing. Fine for one invoice. Now do it 20 times at month-end.

Here’s the same task via API:

curl -X POST https://api.speybooks.com/v1/invoices \
  -H "Authorization: Bearer sk_live_..." \
  -H "Idempotency-Key: inv-feb-acme-2026" \
  -H "Content-Type: application/json" \
  -d '{
    "contactId": "cont_42",
    "lineItems": [{
      "description": "February consultancy",
      "quantity": 1,
      "unitPricePence": 500000,
      "taxCode": "T1"
    }],
    "send": true
  }'

One command. Scriptable. Repeatable. Pipe the output to jq. Wrap it in a loop. Run it from a cron job. Chain it with other tools.

What API-First Actually Means

API-first doesn’t mean “we have an API.” Most modern accounting platforms have APIs. API-first means the API is the primary interface — the dashboard is built on top of it, not the other way around.

The difference shows up in practice:

Dashboard-first with API bolted on:

• Features appear in the dashboard first, API months later (if ever)
• API responses are shaped around the UI’s needs, not the developer’s
• Some operations are only available through the dashboard
• API documentation is an afterthought, incomplete, or wrong

API-first with dashboard on top:

• Every feature is available via API from day one
• API responses are designed for machine consumption (prefixed IDs, minor units, consistent envelopes)
• The dashboard uses the same API that external developers use
• API documentation is a first-class deliverable

When the dashboard and external API share the same backend, bugs get found faster and features ship simultaneously to both interfaces. There’s no “this works in the UI but not the API” class of bug.

What You Can Do With an API

The real power isn’t in replacing clicks with curl commands. It’s in what becomes possible when your accounting data is programmable.

Automated invoicing: your CRM closes a deal, triggers a webhook, and SpeyBooks creates and sends the invoice. No human touches the accounting system.

// Webhook handler: CRM deal closed → create invoice
app.post('/webhooks/deal-closed', async (req) => {
  const { clientId, amount, description } = req.body;

  await speybooks.invoices.create({
    contactId: clientId,
    lineItems: [{
      description,
      quantity: 1,
      unitPricePence: amount,
      taxCode: 'T1',
    }],
    send: true,
  });
});

Month-end reconciliation script: download bank statement, upload to SpeyBooks, review the auto-matched results, confirm in bulk.

#!/bin/bash
# month-end.sh — run on the 1st of every month

# Download last month's bank statement (your bank's export)
LAST_MONTH=$(date -d "last month" +%Y-%m)

# Upload to SpeyBooks
curl -X POST https://api.speybooks.com/v1/bank-imports \
  -H "Authorization: Bearer $SPEYBOOKS_KEY" \
  -F "file=@statements/${LAST_MONTH}-barclays.csv" \
  -F "bankAccountId=acc_1200" \
  -F "format=barclays"

# Generate P&L
curl -s "https://api.speybooks.com/v1/reports/profit-loss?from=${LAST_MONTH}-01&to=${LAST_MONTH}-31" \
  -H "Authorization: Bearer $SPEYBOOKS_KEY" | jq '.data.netProfit'

Slack notifications: get a message when an invoice is overdue, when a large payment lands, or when your VAT liability exceeds a threshold.

Dashboards you actually want: pull financial data into Grafana, Retool, or a custom internal tool. Your accounting data joins your other business metrics instead of living in a silo.

CI/CD integration: run financial checks as part of your deployment pipeline. Verify your books balance before deploying a billing change.

None of this is possible when the dashboard is the only interface.

The Objection: “But I Sometimes Need a Dashboard”

Fair. Some tasks are genuinely better with a visual interface: reviewing a complex balance sheet, exploring unfamiliar data, onboarding a new user.

The point isn’t that dashboards are bad. It’s that dashboards should be optional. The UI is one interface among many — CLI, API, webhooks, SDKs. If the only way to use your accounting software is through a browser, you’re artificially limited.

SpeyBooks has a dashboard. You can create invoices, reconcile transactions, and generate reports through the web interface. But everything you can do in the dashboard, you can also do via the API. The dashboard is built on the same API you have access to.

That means you choose the interface that fits the task: dashboard for exploration, API for automation, CLI for quick operations, webhooks for event-driven workflows.

The Accounting Platform as Infrastructure

Developers don’t think of their database as a “database dashboard.” PostgreSQL is infrastructure — you interact with it programmatically, build applications on top of it, and occasionally use pgAdmin when you need to explore.

Accounting software should work the same way. It’s financial infrastructure. Your books are data. The platform is an API. The dashboard is pgAdmin — useful, but not the primary interface.

This is what we mean by Accounting as Code. Your financial logic belongs in your codebase, version-controlled, testable, and automatable. The accounting platform provides the double-entry ledger, the compliance calculations, and the audit trail. You decide how to interact with it.