What is an API, actually?

Somewhere between Friday night and Monday morning, the actuals moved. They left NetSuite, arrived in your Anaplan model, and were sitting there when you opened it. Nobody emailed a file. Nobody uploaded a CSV.

So how did they get there? An API. You’ve nodded at that word in a dozen vendor calls. This is what you nodded at.

The service desk with fixed forms

API stands for Application Programming Interface. Forget the name, it explains nothing.

Think of every system you use as a building. NetSuite is a building. Workday is a building. So are SAP, Anaplan, and your bank. Inside each one sits data you care about: actuals, headcount, invoices, balances. The API is that building’s service desk, and it’s the most rigid service desk you’ve ever dealt with. It accepts requests only on its own forms, filled in exactly right, and it hands back answers in its own fixed format. No small talk, no judgment calls, no “I’ll see what I can do.”

That’s the whole idea. An API is how one system asks another for something, using forms both sides agreed in advance.

When Monday’s actuals appear in the planning model, what happened overnight is this: a scheduled job walked up to NetSuite’s service desk and submitted a form. May 2026, entity UK01, all P&L accounts, actuals please. NetSuite checked the requester’s pass, pulled the numbers, and handed back a structured reply that a machine can read without guessing. Anaplan loaded it. Minutes, no humans.

sequenceDiagram
  participant A as Anaplan (planning)
  participant N as NetSuite (ERP)
  Note over A: Sunday, 02:00
  A->>N: Form: May actuals, entity UK01, all P&L accounts (+ door pass)
  N->>N: Check the pass and what it may ask for
  N-->>A: Structured reply: the numbers, machine readable
  Note over A: Loaded before you log in Monday

You’ve been the API

If your team exports a CSV from the ERP every month, tidies the columns, and uploads it into the planning tool, I have mildly annoying news: you are the integration. A person doing by hand exactly what two service desks could do with each other on a schedule.

The export ritual isn’t a law of nature. It’s a missing API connection, and it can usually be built.

flowchart TB
  subgraph M[The manual version]
    direction TB
    A1[Someone exports a CSV] --> A2[Someone fixes the columns] --> A3[Someone uploads it, again]
  end
  subgraph P[The API version]
    direction TB
    B1[Scheduled request, 02:00] --> B2[Numbers arrive, checked and logged]
  end

That’s also all an “integration” is. Someone set up the forms, the schedule, and what happens when a request fails. It costs real money because every building designed its own forms, and translating between them properly, with error handling an auditor would accept, is genuine work.

Once you know the shape, you’ll spot it all over your week. Workday headcount landing in the model before a reforecast. Bank balances appearing in the treasury dashboard each morning. A Power BI report refreshing from SAP with nobody touching it. “The integration is down” means one service desk stopped answering. “We got rate limited” means we sent too many requests at once and got put in a queue.

The security part

A service desk doesn’t serve just anyone. Every request carries a key: a long secret that says who’s asking and what they’re allowed to ask for.

This matters more to finance than to most departments, because our buildings hold the crown jewels. Payroll sits in Workday. The full general ledger sits in the ERP. A key with too many permissions is a door pass that opens every room, and if it leaks, whoever holds it can request your data exactly the way your systems do. From anywhere.

Three things worth knowing, because they’ll come up:

• Keys have permissions. A read-only key can look but never touch. The key your dashboard uses should not be able to post journals. When IT asks “does it really need write access?”, this is why, and the right answer is usually no.
• Requests get logged. Good systems record every call: who asked, for what, when. Familiar idea. It’s an audit trail.
• Keys should expire. A key from a vendor trial three years ago that still works today is an audit finding waiting to be written up.

When your IT team takes two weeks to approve a vendor connection, this is what they’re checking. It isn’t obstruction. It’s the posting-access discipline you already apply to people, applied to machines.

Why this is useful to you

Because the plumbing shapes your options.

In a system selection, “do you have an API?” is a weak question. Every vendor says yes. Better: can I pull trial-balance-level actuals out on a schedule, and does that cost extra? Some service desks only accept deliveries and won’t hand anything back. Some charge separately for the useful forms. You want to know before you sign.

Every manual export in your close is a candidate for retirement. Once you can name it as a missing connection, you can scope it and price it, instead of leaving it as a permanent to-do.

And every AI tool you’ll evaluate in the next few years plugs into your systems this exact way. When a vendor says their assistant “connects to your ERP,” they mean it fills in forms at the service desk like everything else does. Same keys, same permissions, same two weeks of IT questions. Nothing mystical is happening behind that demo.

What I’d tell your CFO

APIs are how our systems already talk to each other, and the manual exports in our close mark the places where they don’t. Each of those is buildable and priceable, which is exactly what you want plumbing to be: boring. The questions IT asks about keys and permissions are our own posting-access controls, applied to machines, and they deserve the same respect. Fund the boring plumbing. It’s where the late nights go.

This is part of a series explaining AI and the systems around it for finance people, in their own language. I build AI systems for finance teams; the series is what I’ve learned doing it.