How to recognize duplicated business logic

You fix a discount rule in one place, ship it, and a week later a customer complains they got charged the old price on a different screen. Nothing was actually broken — the rule was just written twice, and you only fixed one copy. If that scenario sounds familiar, you're not dealing with a bug. You're dealing with duplicated business logic, and it's one of the quietest, most expensive problems in any growing custom system.

This article shows you how to actually spot duplicated logic in a live FileMaker, ERP, or custom-built system — not just define the term — so you can fix it before it costs you a customer, an audit finding, or a very confused new developer.

What exactly counts as "duplicated business logic"?

Business logic is any rule that decides what the system should do based on your company's specific way of working: how a discount is calculated, when an order is allowed to ship, which approval an invoice needs above a certain amount, how a shipping cost is derived from weight and destination.

Duplicated business logic means that same rule exists in more than one place in your system — written independently, not shared. It's different from duplicated data (the same customer record stored twice) or duplicated UI (two screens that look similar). Duplicated logic is about the same decision being coded twice, which means it can drift apart the moment one copy changes and the other doesn't.

A concrete example: a FileMaker solution calculates a 5% loyalty discount inside a script triggered from the Sales layout. Six months later, someone builds a quick order form for the webshop connector, and instead of calling that existing script, they retype the same 5% rule as a calculation field on the new layout. Both work fine — until marketing changes loyalty discounts to 7%. Now one order channel applies 7% and the other still applies 5%, and nobody notices until finance reconciles the numbers.

Why does duplicated logic happen even in well-run teams?

It's rarely laziness. It usually happens for very reasonable, human reasons:

• Deadline pressure. Copying an existing calculation is faster than tracing where it lives and refactoring it into something reusable.
• Unclear ownership. In a system that's grown for years, nobody is fully sure which script or field is the "official" source of a rule, so a new developer just writes their own version to be safe.
• Multiple entry points. A modern business system rarely has one interface anymore — there's the desktop FileMaker client, a WebDirect or FmBetterforms-based portal for external users, and an API connector feeding data to an accounting package. Each entry point tempts a developer to re-implement the rule locally instead of calling back into a shared one.
• No documentation of where rules live. If there's no map of "pricing lives in Script X, shipping cost lives in Field Y," every new feature is a coin flip between reusing and reinventing.

What are the warning signs you can check for right now?

You don't need a full code audit to start noticing duplication. Walk through these checks:

1. Search your scripts and calculations for the same keyword or constant. In FileMaker, use Manage Scripts and Manage Database to search for a specific number (like a tax rate or a fixed fee) across every script and calculation. If it appears in three unrelated places, that's a strong signal.
2. Compare behavior across channels. Place the same test order through every entry point — the desktop client, the customer web portal, the API — and check whether the discount, tax, or shipping cost matches every time. Any mismatch usually traces back to duplicated logic, not a random bug.
3. Ask "if this rule changed tomorrow, how many places would I have to update?" for your five most business-critical rules (pricing, tax, approval thresholds, stock allocation, commission). If the honest answer is more than one, you have duplication.
4. Look for near-identical scripts with slightly different names, like "Calculate Discount," "Calculate Discount v2," and "Calculate Discount – Webshop." These names are almost always evidence that someone didn't trust or couldn't find the original.
5. Check whether business rules leak into the interface layer. If a validation rule ("orders under €50 need manager approval") is written directly into a button's script step on one layout, and separately into a portal filter on another, you've got the same logic living in two unrelated layers of the system.

How does duplicated logic actually cost you money?

It's easy to treat this as a tidiness issue, but it has direct business consequences:

• Inconsistent customer experience — one channel honors a promotion, another doesn't, and support has to explain the discrepancy.
• Compliance risk — if an approval threshold or tax rule is updated in your ERP for a new regulation but the API connector still uses the old hardcoded value, you may be generating invoices that don't meet current requirements.
• Slower development — every new feature has to account for "which copy of this rule do I need to touch," which quietly taxes every future change.
• Harder onboarding — a new in-house developer or an outside partner brought in to extend the system has to reverse-engineer which version of a rule is actually authoritative, which slows down every project estimate.

How do you fix duplicated logic once you've found it?

Finding it is only half the job. A few practical steps that work well in FileMaker and similar custom systems:

1. Pick the authoritative version. Decide which copy of the rule is correct today, and treat every other copy as the one to retire.
2. Centralize it in one place the whole system can call. In FileMaker this often means moving logic into a single script or a custom function that every layout, portal, and API endpoint calls — rather than three separate calculation fields doing the same math.
3. Route every entry point through that single source. Whether the request comes from WebDirect, a FmBetterforms form, or an external API integration, it should trigger the same underlying logic rather than a re-implemented copy.
4. Delete the duplicates — don't just leave them dormant. Unused near-duplicate scripts are exactly what causes the next developer to accidentally build on the wrong one.
5. Document where the rule now lives, even briefly, so the next person doesn't have to rediscover it the hard way.

Some teams introduce a small internal tool or AI-assisted script search (this is one area where adding AI inside FileMaker genuinely pays off) to scan for repeated calculation patterns automatically, rather than relying on manual memory of where every rule sits.

Is this only a FileMaker problem?

No — duplicated business logic shows up in every kind of system: ERP customizations, spreadsheets that mirror database rules, custom web apps, and API middleware. It tends to get worse specifically in low-code and rapid-development platforms like FileMaker precisely because they make it so easy to add a new calculation field or script step in minutes. That speed is a huge advantage for getting features out fast, but without some discipline around where logic lives, it's also exactly what lets duplication creep in unnoticed. This is one of the specific maintainability risks covered in more depth in how to keep business software maintainable as it grows.

A quick checklist to catch duplication before it spreads

• Search scripts/calculations for repeated constants (tax rates, fees, thresholds)
• Test the same transaction through every channel (desktop, web portal, API) and compare results
• List your top 5 business-critical rules and confirm each lives in exactly one place
• Flag scripts with version-like names ("v2," "new," "webshop copy")
• Confirm validation rules aren't split between interface layer and data layer
• Review this list again after every major feature release, not just once a year

FAQ

How often should I check for duplicated logic? Treat it like a light audit — a quick pass after every major feature, and a fuller review once or twice a year as the system grows.

Can duplicated logic ever be intentional or acceptable? Occasionally, for genuinely isolated one-off rules that will never need to match another part of the system. But for anything tied to pricing, compliance, or customer-facing behavior, treat duplication as a defect, not a shortcut.

Does adding an API connector increase the risk of duplication? Yes, if the connector re-implements rules instead of calling into the existing system logic. A well-designed integration should trigger the same script or function the main application uses, not reproduce the calculation independently.

Is this something only a developer can catch? Business owners and managers can spot the symptoms too — inconsistent discounts, mismatched invoices, support tickets about "it worked yesterday." Those are exactly the signals worth raising with whoever maintains the system.

If this checklist turned up more duplicated rules than you expected, that's a normal sign of a system that has grown organically over the years — not a sign it needs to be rebuilt from scratch. Loggix regularly helps teams trace where business logic actually lives inside a FileMaker or connected ERP environment, consolidate it into a single, maintainable source, and wire up API integrations or AI tools so every entry point — desktop, web, or external system — plays by the same rules. Sometimes that's a focused cleanup project; sometimes it's a short consultancy session to map out where the risk really sits before deciding what to touch first.