Your business rules engine already exists.
It's called Excel.
Most teams shopping for a business rules engine already have one: a spreadsheet the business maintains and trusts. SpreadAPI turns that Excel model into a governed decision API — without a six-figure migration or a new tool anyone has to learn.
What a business rules engine is really for
Strip away the vendor jargon and every business rules engine promises the same four things. The question is what it costs you to get them.
Logic out of the codebase
Pricing, eligibility and risk rules change weekly. They should never require a developer, a pull request and a deploy every time.
The business owns the rules
The people who understand the rules — pricing, underwriting, finance — should be able to change them directly, without translating them for engineering.
A callable decision API
Your app, workflow or AI agent sends the inputs and gets back a decision. No copy-paste, no re-implementation, one source of truth.
Governed and transparent
Every decision has to be explainable and controlled: clear inputs and outputs, private logic, and a version you deliberately publish.
You already built your rules engine — in a spreadsheet
In almost every company, the rules you want to manage already live in an Excel file. The pricing team built the price list. Underwriting built the risk model. Finance built the commission logic. It works, everyone trusts it, and it is edited every week.
The traditional pitch asks you to throw that away: re-express every rule in a proprietary language or DMN table, retrain the business on a new IDE, and run a migration project that spans quarters — all to recreate what your spreadsheet already does correctly today.
SpreadAPI takes the opposite path. The spreadsheet is the rule definition. You publish it, and you get the decision API — in minutes.
“Don’t buy a business rules engine. You already own the best one: the Excel model your team maintains every day.”
Excel-native vs. a traditional BRMS
Traditional BRMS = Drools, InRule, IBM ODM, Camunda and similar decision-management platforms.
From spreadsheet to decision API in three steps
Upload the Excel that holds your rules
The same file your team already maintains — VLOOKUPs, nested IFs, rate tables, financial functions and all. Nothing to rebuild.
Define the decision contract
Point to the cells that are inputs (the case data) and the cells that are outputs (the decision). That contract is all the API exposes.
Call the decision from anything
Your backend, an n8n or Zapier workflow, Power Automate, or an AI agent sends the inputs and receives the decision as JSON.
If it lives in a spreadsheet, it can be an API
Anywhere the business encodes “given these inputs, what’s the answer?” in Excel, SpreadAPI turns it into a decision service.
Pricing & discount tiers
Volume breaks, regional pricing, customer-specific rates.
Underwriting & risk scoring
Insurance premiums, risk classes, acceptance rules.
Credit & eligibility
Loan qualification, limits, scorecards, affordability checks.
Commission & payouts
Sales commission tiers, bonuses, partner revenue shares.
Quoting & configuration
CPQ logic, bundles, add-ons, feasibility rules.
Tax, fees & surcharges
Jurisdiction rules, duties, thresholds, rounding.
The parts your risk team asks about
The danger with spreadsheets was never Excel — it was emailing copies around and pasting values. SpreadAPI removes exactly that.
Your logic stays private
The API returns the decision, never the formulas or the sheet. Callers see inputs and outputs — never how you get there.
Separation of duties
The business owns and edits the model in Excel. Developers only consume a stable endpoint. Neither side blocks the other.
One controlled version
Consumers always call the version you deliberately published. Work-in-progress edits stay in draft until you release them.
On-premises option
For regulated data, run the entire engine inside your own infrastructure. The spreadsheet never leaves your network.
Questions worth asking
Isn’t a spreadsheet riskier than a real business rules engine?
The risk in spreadsheets comes from uncontrolled copies and pasted values — not from Excel itself. SpreadAPI removes that: one published model, called by API, formulas never exposed, results calculated by the real Excel engine. You keep Excel’s transparency and lose the copy-paste chaos.
How is this different from Drools, InRule or IBM ODM?
Those engines require you to re-author your rules in their language and run a migration project. SpreadAPI uses the Excel model your team already wrote. No re-authoring, no new skill set, no migration.
Can business users change rules without a developer?
Yes. They edit the spreadsheet and publish. As long as the input and output cells stay the same, the API contract is unchanged — so nothing downstream breaks.
What about complex logic — VLOOKUP, nested IFs, financial functions?
All 500+ Excel functions run exactly as they do in Excel, with the same results. Complex, interdependent models are precisely the point.
How fast is a decision?
Typically 50–200 ms per calculation, so it fits inside real-time pricing, checkout and application flows.
Can we run it on our own infrastructure?
Yes. On-premises deployment is available for regulated industries and data-sovereignty requirements.
Stop migrating rules. Start calling them.
Turn the Excel model your team already trusts into a governed decision API. No migration, no new tool, no six-figure license.