Bramvia — Business Central Experts
ERP projects have a reputation for budget overruns and disputes. Our answer is structural: the project is split into parts, and each part is invoiced only after you've accepted it.
Ask a finance director about ERP projects and you'll usually get a story — theirs or a colleague's — about a project that ran long, cost more than agreed, and delivered less than promised.
That reputation is why the hardest part of selling ERP consulting isn't explaining the technology. It's the buyer's entirely reasonable fear that they'll commit budget and end up with a problem that has their name on it.
We think the honest response to that fear is structural rather than rhetorical.
How we work
The project is divided into parts. Each part is paid only after it is finished and you have accepted it.
There's no payment up front and nothing held back at the end. We complete a part, you review it against what was agreed, you accept it, and only then is that part invoiced. If a part isn't accepted, it isn't paid.
The first conversation, the indicative estimate and the initial scoping are free and carry no obligation.
Why we structure it this way
It puts the risk where it belongs. We're the ones claiming we can deliver. We should carry the risk of proving it, not you.
It forces honest scoping. When you're paid on acceptance, you cannot afford vague requirements. It's in our own interest to define precisely what "done" means for each part before starting — which is exactly the discipline ERP projects most often lack.
It surfaces problems early. With a single delivery at the end, a misunderstanding in month two isn't discovered until month eight. With acceptance at each part, you find out in week three, when it's cheap to fix.
It makes stopping possible. If after two parts you're not happy, you stop. You've paid for what you accepted and you keep it. That option is what makes the first commitment reasonable.
What this is not
We're not claiming this is unique, and we won't characterise how other firms work — plenty of consultancies run fair fixed-price engagements, and a fixed price with clear scope is a perfectly legitimate model.
The general failure pattern in this industry isn't dishonesty. It's vague scope. When "implement the ERP" is the agreement, every unanticipated requirement becomes a negotiation, and both sides end up frustrated. Acceptance-based delivery in parts attacks that specific problem by forcing precision about what each part contains.
We're also not claiming this makes projects risk-free. It doesn't. It means you're not paying for outcomes you haven't received.
What to ask any partner
Whoever you choose, these are worth asking:
- What exactly is included, and what is explicitly out of scope?
- What happens when a requirement emerges that wasn't anticipated?
- When do payments fall due, and against what?
- What does "complete" mean for each phase, and who decides?
- What happens if we want to stop?
A partner who answers those clearly is a reasonable bet regardless of their pricing model. One who can't is a risk whatever they charge.
Book a free, no-obligation conversation — and if we're not the right fit, we'll tell you.
FAQ
What does pay-on-acceptance mean exactly? The project is split into parts with written acceptance criteria. Each part is invoiced only after you accept it. No upfront payment, no retainers.
What if we don't accept a part? You don't pay for it. We fix it or the scope is adjusted — the risk sits with us, which is where it belongs.
Free assessment · Evaluación gratuita
Tell us your current system and how many users you have. First reply within one working day. / Cuéntanos tu sistema actual y cuántos usuarios sois. Respondemos en un día laborable.
Bramvia in: Spain · United States · Mexico · United Kingdom · Ireland · Canada · Colombia · Argentina · Chile · Peru · Australia · New Zealand · South Africa · Philippines · Poland · MCP server · Safety stock calculator