Reporting
Built for banks, not for 990s: the reporting work that lands on you
Your bank and your fintech hand you data built for a business. Turning it into something the IRS and your board accept — program codes, restrictions, functional expenses — is work no tool does for you. So you do it, every month, by hand.
Three columns in. The columns a 990 needs? You add those yourself.
The scenario
Every month, Hannah downloads the same file: a bank export with three columns — date, amount, and a cramped description line. It’s clean, it’s accurate, and it’s built for a business checking account. It is not built for a nonprofit.
So the real work begins. She opens the accounting software and starts adding what the bank never captured: which program each transaction belongs to, whether the funds were restricted by the donor, which grant they draw against, and how each expense splits across program, admin, and fundraising for the 990. The bank gave her three columns. Her 990 needs six more — and she types every one of them herself.
One month of transactions
What the bank gives you vs. what a 990 needs
The bank designed its file for a business checking account. Program coding, donor restrictions, and the functional-expense split every 990 requires? You add all of it — every transaction, every month.
Here’s the quiet truth about nonprofit finance software: almost none of it was built for nonprofits. Banks build for businesses; general fintechs build for e-commerce. What they hand you is a clean, accurate record of money moving — and nothing about why it moved in the terms the IRS and your board actually care about.
A Form 990 doesn’t just ask what you spent. It asks how every dollar splits across program, management, and fundraising — the functional-expense breakdown. Your board asks which gifts were restricted by the donor and which grant each expense draws against. None of that is in a bank export, because a bank has no idea your organization has programs, restrictions, or grants. So you supply it — by hand, line by line.
The mechanics are numbingly familiar. Download the file. Import it. Then, transaction by transaction, add the columns the bank never had: which program, which fund, restricted or unrestricted, which grant, how the expense allocates for the 990. A team touching 250 transactions a month is making 250 coding judgments — and typing them — three thousand times a year, each one a small chance to miscode something an auditor will later find.
And the cost isn’t only the hours. It’s that your compliance now rests on a manual process a single distracted afternoon can quietly break — and that the people doing this work are usually your most senior, most expensive finance staff, because coding a restricted grant correctly takes judgment, not just data entry.
The takeaway: ask whether your money data arrives already coded to your programs, restrictions, and functional-expense categories — or whether you add all of that yourself. If it’s the latter, you’re doing the software’s job, at senior-staff wages.
Your bank built its export for a business. The work of turning it into a 990 falls entirely on you.
Where SNDR fits
SNDR captures the fields a 990 filer actually needs — program, fund, donor restriction, grant, functional-expense category — at the moment money moves, not months later in a spreadsheet. Records arrive already coded the way your auditor and your board expect, so “getting audit-ready” stops being a project.