I run finance at Athena. I am not an engineer, and I have never asked one to build me an integration. QuickBooks, Brex, Bill.com — the connections our monthly close runs on were built by this team, in plain language, inside the platform we sell.
Here is what that actually looked like, because “no-code” stories usually hide the seams.
The month-end close used to be the standard artifact-shuffle: export from QuickBooks, cross-check card transactions in Brex, chase invoices in Bill.com, staple it together in a spreadsheet nobody else could maintain. The first thing we did was describe that procedure to Athena the way you would describe it to a new hire — where the numbers live, what “reconciled” means to us, which mismatches matter and which are noise.
The procedure became an AOP: versioned, scheduled, inspectable. When it runs, it pulls from all three systems, builds the reconciliation in a live spreadsheet, and flags the exceptions — with every cell attributed, so when the controller reviews it, “where did this number come from” has a clickable answer.
The part worth dwelling on: when an integration needed to exist, we said so in natural language, and the agent assembled it — authenticated connection, field mapping, the retry behavior when Bill.com has a bad morning. An engineer reviewed the access scopes, because governance is governance. Nobody wrote integration code for us.
What this says about who software is for: the historical deal was that operators describe what they need and engineers translate it, with a queue in between. The queue is where operational software goes to die — every finance team runs on workarounds that never justified an engineer’s sprint. The deal we work under now is that the operator’s description is the implementation, and engineering’s job is the platform that makes that safe: access governance, attribution, rollback.
“Both workforces” is usually heard as engineers plus agents. The month our close ran itself, it started meaning us.
— Finance, New York