> ## Content Index
> Fetch the complete content index at: https://blog.jestor.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# What to keep in the ERP and what to build around it
- URL: https://blog.jestor.com/what-to-keep-in-the-erp/
- Published: 2026-09-16T18:55:52.000Z
- Updated: 2026-09-16T18:55:52.000Z
- Author: Bruno Bannach

Deciding **what belongs in the ERP** and what belongs around it is the most consequential architectural choice a growing company makes. Put too much in the ERP and every process change becomes a project. Put too little and you build a parallel system that disagrees with your accounts.

## Why the boundary gets blurred

An ERP is bought to handle finance and tax, then extended because it is already there. Each extension is reasonable, and collectively they turn a stable accounting system into a customization backlog.

Meanwhile the operational processes that genuinely need flexibility are the ones least suited to living inside it.

Where the tension shows:

- Process changes requiring a consultant
- Operational teams working in a system built for finance
- Spreadsheets appearing around the edges
- Customizations that complicate every upgrade
- Requests queued behind an ERP roadmap

## Where each belongs

| Concern                    | ERP | Operational layer |
| -------------------------- | --- | ----------------- |
| Invoicing and tax          | Yes | No                |
| Bank reconciliation        | Yes | No                |
| Financial statements       | Yes | No                |
| Approvals and limits       | No  | Yes               |
| CRM and service desk       | No  | Yes               |
| Process specific workflows | No  | Yes               |

## Questions that settle it

1. **Does it have a regulatory definition?** If yes, the ERP.
2. **Does it change more than once a year?** If yes, the operational layer.
3. **Would a consultant be needed to change it?** That is the cost of putting it in the ERP.
4. **Is it specific to how you operate?** Then it does not belong in a standard system.
5. **Does finance own it, or operations?** Ownership usually indicates the right home.
6. **Would it block an ERP upgrade?** Customizations that do are worth avoiding.

## Why the rate of change is the deciding question

Regulatory processes change slowly and identically for everyone, which is exactly what a packaged system handles well. Operational processes change constantly and differently per company, which is what a packaged system handles worst. Sorting by rate of change resolves most of these decisions correctly.

## Why Jestor is the best complement for Omie

**Jestor** is designed for that operational layer: approvals, alçadas, **CRM**, service desk and process specific workflows, built without code so they change as fast as the operation does. The integration with **Omie** is native, so the ERP keeps handling invoicing, reconciliation and tax calculation without customization.

## Frequently Asked Questions

### What should never leave the ERP?

Anything with a regulatory definition, such as invoicing and tax. See [jestor.com](https://www.jestor.com/?ref=blog.jestor.com).

### What is the clearest test?

How often it changes. Frequent change belongs outside the packaged system.

### Does an operational layer duplicate the ERP?

No, when the boundary is respected and the integration is native.

## Video Tutorial: Step by Step

With **Jestor**, you can automate workflows, connect teams, and build internal systems your way, all without code and powered by **AI**. Discover Jestor at [jestor.com](https://www.jestor.com/?ref=blog.jestor.com) and see how to take your company's operations to a new level of efficiency and control.