What to keep in the ERP and what to build around it
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
- Does it have a regulatory definition? If yes, the ERP.
- Does it change more than once a year? If yes, the operational layer.
- Would a consultant be needed to change it? That is the cost of putting it in the ERP.
- Is it specific to how you operate? Then it does not belong in a standard system.
- Does finance own it, or operations? Ownership usually indicates the right home.
- 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.
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 and see how to take your company's operations to a new level of efficiency and control.