Monday, 9:40 a.m. An electronic invoice for a major customer just got rejected, and month-end close is due Thursday. You open a ticket with your provider and the answer arrives that afternoon: "that's a new requirement, we'll send you a quote." You pay for support every month, but nobody ever told you what it covered.
An SAP Business One support contract rarely fails because of bad faith. It fails because nobody wrote down exactly what gets handled, how fast, with how many hours, and what happens with upgrades. Below is what's worth putting in writing and how the work is split between your partner and SAP. It's useful if you're signing for the first time, and also if you're reviewing the SAP B1 maintenance you already pay for.
Who does what: your partner, SAP and your team
SAP doesn't serve Business One customers directly. According to its own support page, the product is sold, implemented and supported through its partner network. A valid maintenance contract gives you new versions and patches at no extra cost, 24x7 support for critical issues, and proactive tools like the Remote Support Platform, which checks database health and sends the results to SAP and to your partner.
In practice, the split looks like this:
- Your partner takes the case, diagnoses it, looks for known notes and patches, and fixes it if it's a configuration, data or custom development issue.
- SAP steps in only when the partner isolates a reproducible product defect and escalates it.
- Your internal team, usually one key user per area, filters how-to questions before they become tickets.
The annual maintenance you pay SAP (through the partner) and the partner's support service are two different things, even when they show up on the same invoice. The first entitles you to versions and patches. The second is who answers you on Monday at 9:40. A good contract keeps them separate.
What the contract should say, clause by clause
If any of these points is missing from your contract, ask before you sign or renew.
| Contract item | What it should say | Red flag |
|---|---|---|
| Scope | Which modules, companies, add-ons and integrations are covered | "Full support" with no list |
| Case types | The difference between incident, question and new requirement | Anything short of an outage gets quoted separately |
| Times | Response and resolution by priority, business hours or 24x7 | Only a "first response" time |
| Hours | Monthly bank, what consumes hours, what happens to unused ones | Hours that expire with no usage report |
| Channels | Portal or service desk with ticket numbers | A consultant's WhatsApp as the official channel |
| Upgrades and patches | Who plans them, how they're tested, whether they're included | "Quoted when needed" |
| Add-ons and custom work | Who answers for each one and for its compatibility | Third-party add-ons with no clear owner |
| Documentation | Configuration and developments delivered and kept current | Knowledge lives in one person's head |
| Reporting | Monthly report on tickets, times and hours | No report, or one nobody asked for |
| Exit | Handover of source code, documentation and transition if you switch partners | Silence on how the contract ends |
For more on reading response times and penalties, see Managed IT services SLA: what to demand and how to read it.
Incident, question or requirement: where most arguments start
An incident is something that used to work and stopped: a rejected tax document, a report that doesn't add up, an error when posting. A question is a how-to doubt. A requirement is something new: an extra field, a report that never existed, an integration with another platform.
The contract should define all three with examples from your own operation, not generic definitions. It also helps to agree on priorities by impact. An invoice you can't issue isn't as urgent as a misaligned print layout.
Chile has a special case: electronic invoicing. The SII's Purchase and Sales Register (RCV) is built from the electronic tax documents (DTE) the tax service receives, so an issuing error in the ERP ends up affecting the monthly tax return. In SAP B1 this usually runs through an add-on or an e-invoicing provider. Write down who responds when the SII rejects a document: your partner, the add-on vendor, or both under a clear procedure.
SAP Business One upgrades: in or out of the contract
SAP releases version 10.0 feature packs twice a year: FP 2602 came out in February 2026 and FP 2608 in August. And according to its maintenance strategy, version 10.0 is in mainstream maintenance until December 31, 2028, with dates subject to change, and version 11 will follow.
Why should you care? Because falling too far behind has a cost. Some new features, like Service Layer webhooks, need FP 2602 or later, and their advanced options need FP 2608. And because every upgrade forces a compatibility check on add-ons and custom developments.
Ask your partner:
- Whether upgrades are included in support or quoted as a separate project.
- How often they suggest upgrading and how they decide when to wait.
- Whether they test in a staging environment before touching production.
- How they check each add-on's compatibility with the new feature pack.
- What their plan is for moving to version 11 once SAP publishes dates.
Some partners upgrade as soon as a feature pack ships and others prefer to wait for the next patch. Both positions are defensible if they're in writing. For the technical side of versions and roadmap, we have a dedicated article: SAP Business One: support, upgrades and roadmap.
Signs your support isn't working
Sometimes the contract is well written and the service still falls short. You can usually tell before the crisis:
- The same incidents come back every month and nobody looks for the root cause.
- Each ticket goes to a different person who asks for the same information again.
- You don't know which feature pack you're on or when the next upgrade would be.
- Contracted hours get used up, but you never see a report showing how.
- Nobody can explain what a stored procedure or an add-on running in production does.
- Month-end close slips because of system problems, not business ones.
If you recognize three or more, review things before you renew.
How to review your current contract in a week
Better support doesn't always mean switching partners. Often it's enough to show up at renewal with data:
- Export the last six months of tickets and sort them into incidents, questions and requirements.
- Count how many repeat and how long they took to close.
- Compare billed hours with what actually got resolved.
- Confirm your version and feature pack under Help > About SAP Business One.
- List your add-ons and integrations and ask who answers for each.
- Bring all of that to the renewal conversation and ask for specific changes based on the table above.
Frequently asked questions
Does SAP's annual maintenance include my partner's support?
Maintenance gives you new versions, patches and escalation to SAP for product defects. Day-to-day support, configuration and custom work come from the partner, under the contract you sign with them.
Do I have to upgrade to every new feature pack?
No, but staying several feature packs behind cuts you off from new features and makes the next jump heavier. It's better to agree on a policy for when and how to upgrade.
Can I switch support partners without reimplementing?
Yes. The data and configuration are yours. You'll need the documentation and source code for any custom work, and the maintenance handover should be planned ahead of time.
Let's review your SAP Business One support
At Disrupsoft we work with companies that already run SAP Business One: corrective and evolutionary support, migrations and upgrades, and integration with Azure, Power Platform and Power BI. If you're not sure what your current contract covers, we start with a diagnosis of your instance and your tickets from the last few months. Learn more on our SAP services page.
