What it means
Every company runs on rules that are rarely written down in one place. A credit limit of $50,000 for new accounts, a 2% discount for payment within ten days, a second signature required above $10,000: all of these are business logic.
They sit in policy documents, in people's heads and, increasingly, inside software. In software architecture the term has a precise home.
The presentation layer shows information, the data layer stores it, and the business logic layer in between decides what is allowed and what each action means. Keeping the rules in that middle layer means a change to discount policy happens once rather than in every screen and report.
Finance teams meet business logic most often as a reconciliation problem. If the sales system treats an order as revenue when goods are shipped while the accounting system recognises it when the invoice is raised, the two will never agree at month end, and the difference is a rule rather than an error.
Finding and documenting that rule is the only way to close the gap. Badly placed logic is expensive.
Rules buried in spreadsheet formulas, report filters or one person's routine are invisible, untested and impossible to audit, so a change in pricing or credit policy quietly fails to apply in half the places it should. The cure is to write each rule down, name an owner and implement it in one place.
The rules themselves also need governance. Each should state the condition, the action, the exception and who may override it, because an undocumented override is how a credit policy becomes decorative.
For a smaller company a short rules register is usually enough. One nuance to keep in mind is the difference between business logic and validation.
Validation checks that data is well formed, such as a date being a real date, while business logic decides what the data means for the company, such as whether that date makes an invoice overdue. Confusing the two produces systems that accept perfectly clean data and still reach the wrong decision.
In practice
Real-world examples.
Example
A subscription business decides that a customer who downgrades mid-month keeps the higher service level until the next billing date. That single rule lives in the billing system, the revenue recognition schedule and the customer service script, so when the policy changes all three have to change together.
Example
A wholesaler's credit rule blocks new orders once a customer exceeds $25,000 of overdue balance. A sales manager holds override rights, and because the overrides were never logged, $180,000 of the receivables ledger turned out to sit behind informal exceptions.
Example
A manufacturer's costing system allocates factory overhead by machine hours while its quoting spreadsheet allocates by labour hours. Two quotes for the same job differ by 9%, and the real fix is to agree one allocation rule rather than to patch the spreadsheet.
Formula
Calculation
Business logic is expressed as rules rather than one formula, but each rule can be written as a condition and a calculation. A typical receivables rule set gives: invoice due = (unit price x quantity) - volume discount - settlement discount + late payment charge
Worked example: a customer orders 500 units at $40 each, so the gross invoice is 500 x 40 = $20,000. The pricing rule gives a 5% volume discount on orders above 400 units, which is 20,000 x 0.05 = $1,000, leaving $19,000. The settlement rule offers a further 2% for payment within ten days, which is 19,000 x 0.02 = $380, so prompt payment settles the invoice at $18,620. If the invoice is instead paid a month late, the overdue rule adds 1.5% a month, which is 19,000 x 0.015 = $285, so the amount due becomes $19,285. The same order produces three different amounts, and which one reaches the accounts depends entirely on the logic applied.Case study
Seen in the real world.
Halden Office Interiors is a fictional commercial fit out supplier used here as an illustrative example. Its sales team quoted from a spreadsheet that applied a 12% margin uplift, while the accounting system invoiced from a price list that had been moved to a 15% uplift six months earlier.
Nobody noticed until a customer queried an invoice. The investigation found 240 orders quoted under the old rule and invoiced under the new one, a difference of about $190,000 that the company had to either absorb or chase from customers holding a written quote.
The company moved the pricing rule into one place, its order system, and rebuilt the quoting spreadsheet to pull from it rather than hold its own copy. In this illustrative example the money was lost to a duplicated rule rather than a wrong rule, which is the more common failure in practice.
Watch out
Common mistakes.
- Treating business logic as a purely technical concern, when the rules are commercial decisions that finance and operations own.
- Holding the same rule in several places, such as a quoting spreadsheet and a billing system, so the two drift apart without anyone noticing.
- Allowing undocumented overrides, which turns a credit or discount policy into a suggestion and hides real exposure in the receivables ledger.
Questions
People also ask.
Where should business logic live in a system?
In one identifiable layer or service that every other part calls, so a policy change is made once and applies everywhere at the same time.
Why do two reports show different numbers from the same data?
Almost always because they apply different business logic, such as a different cut off date, a different revenue trigger or a different allocation rule.
How do we document business logic without writing a manual?
Keep a short rules register listing each rule's condition, action, exception, owner and the system that enforces it, then review it whenever a policy changes.
From the founder's library
Take it further with the book.
Build your financial confidence beyond this definition. Shihan's full-length guide, Accounting Fundamentals, takes the same plain-English approach and turns it into a complete, practical playbook for non-finance managers, business owners and students - with chapter-end quiz answers and presentation slides included.
25% off with code MMHQ25, applied at checkout. Priced in USD - checkout may show the equivalent in your local currency.
View the book and save 25%