When you connect your business system (ERP) to an e-commerce platform or a digital customer portal, you need to define early on how the systems will work together. What information will be shared, which system is responsible for what, and how will you make sure everything works as it should? The answers belong in a requirements specification, which should be ready before you ask for solution proposals. Every requirement in it should have an owner, a test case and a definition of an approved result.
Most integration projects that overrun do so for the same reason: the parties signed before they had agreed on what would be built, who would build it and who is responsible when it stops working. The platform vendor starts from its API, the ERP vendor from its own and the implementation partner from its quote. Error handling, monitoring and responsibility after launch fall between the cracks, because none of the three was ever asked.
According to Litium's report Nordic Digital Commerce in B2B 2026, 81 per cent of Nordic B2B companies sell through digital channels, and 31 per cent of revenue is digital. When almost a third of revenue comes in digitally and has to reach the business system, the connection deserves its own requirements specification, separate from the one that covers the e-commerce platform or customer portal as a whole.
How an integration is built, with architecture choices, data flows and project steps, is covered in the guide How to integrate ERP with a B2B webshop in 2026. This post covers the step before that: which requirements you need on paper before the contract is signed, and which questions to put to the platform vendor, the ERP vendor and the implementation partner.
1. Write every requirement so that it can be tested
A requirement such as "the integration must be scalable" or "prices must be synchronised in real time" cannot be approved or rejected. The vendor can answer yes without having promised anything, and you only discover the difference during acceptance testing.
Give every requirement four attributes: an owner on your side, a priority, a test case and a definition of an approved result. The real-time requirement then becomes something like this: a contract price changed in Monitor must be shown to the logged-in customer within five minutes, tested by changing the price of three items for two customers with different agreements. That is a requirement a vendor can answer, and you can check the answer.
Bevent Rasch, which doubled its order intake after launching its digital sales room, names the requirements specification as a decisive success factor. Project manager Martin Hjalmarsson puts it like this: "If you think you have everything under control, review it one or more times with your partners. Otherwise, there is a risk that different parties in the project have different views of what should and should not be included, which means that the work can take longer than expected."
Questions to ask every vendor:
- Which of our requirements do you meet with standard functionality, which with configuration and which require development?
- Which of the requirements have you delivered before against the same business system and the same version?
- Who on your side owns the requirement during the project, and who takes it over after launch?
- How is a requirement that cannot be met as written documented, with consequence, alternatives and decision?
2. State the source of truth and maximum delay for each data object
The most common gap in a requirements specification is that data flows are described as arrows between systems. An arrow says nothing about which system owns the information, who may change it or how old it may be when the customer sees it.
Set out one row per data object: product, price, stock, order, customer and invoice data. For each row, state the source of truth, which system may change the value, which direction it is sent in, which event triggers an update and the longest delay you will accept. Add a column for what the platform should show if the update does not arrive, because that is the behaviour the customer meets on the day something goes wrong.
The trade-offs themselves are described in other posts, so they are not repeated here. The division of roles between business system, PIM (Product Information Management) and order management is covered in ERP for e-commerce: 5 things that actually determine whether it works. Stock types, synchronisation methods and multiple warehouses are in How to sync ERP and stock data in B2B e-commerce, and the pricing logic in the guide to customer-specific pricing.
Requirements to get answered in writing:
- Which system is the source of truth for each field, and can this be shown per field rather than per system?
- How is the same customer, item and order identified in both systems?
- What actual delay have you measured per flow for a comparable customer?
- What happens when a value is changed in both systems at the same time, and how is the conflict shown?
- How are new fields in the business system handled that the platform does not know about?
3. Require an error process for every flow
A demo shows an order that goes through. The requirements specification needs to describe what happens to the order that does not, because that is what decides how much manual work the integration creates after launch.
Distinguish between two kinds of error. A temporary error, such as a timeout or a business system that is down for maintenance, should be resolved by controlled retries without anyone having to act. A data error, such as an order with a customer number that does not exist in Jeeves or an item that has changed unit, cannot be fixed by retrying. Someone has to correct the master data, and the integration should show who and what.
The requirement most often missing concerns resending. When a message is sent a second time, it must not create a second order. Ask the vendor to show how the same order is recognised when it is resent, and ask to see it in a test environment rather than in an architecture diagram.
Requirements to set:
- Which error types are handled automatically, and which require manual action?
- How many retries are made, at what interval, and what happens when they run out?
- Where does an order end up that cannot be sent, and what status does the customer see in the meantime?
- How are duplicates prevented when a flow is rerun?
- Can a single flow be paused without affecting the others?
- Who on our side receives the error, and in which interface is it resolved?
4. Set requirements for monitoring that catches silent failures
A flow that crashes is noticed the same day. A flow that keeps running but sends zero orders, or yesterday's stock balance, can go on for a week before a customer calls to ask. That is why requiring alerts for technical errors is not enough.
Require the monitoring to show three things per flow: when it last succeeded, how large the delay is right now and how many messages are waiting in the queue. Then add alerts on business patterns. Zero orders on a weekday, an unusual number of rejected prices or stock balances that change sharply overnight are all signs that something is wrong, even if the integration technically reports that everything went through.
The log should make it possible for customer service to follow a single order through the whole chain without asking a developer for help. That means search by order number, customer number and item number, and one line per step with time, source, recipient, status and the result of any retries.
Requirements to set:
- Which deviations are detected automatically, and which require someone to look at a view?
- Who receives the alert, and how quickly must it be acknowledged?
- Can customer service search for an order themselves and see where it stands?
- Which metrics are reported on an ongoing basis after launch, and to whom?
- How long are the logs kept, and how are customer and price data protected in them?
5. Document responsibility between the platform vendor, the ERP vendor, the partner and yourselves
An ERP integration has at least four parties: you as the customer, the platform vendor, the ERP vendor and the implementation partner. When an order gets stuck, it is rarely obvious whose part of the chain has failed, and without a shared escalation path each party spends its time showing that the fault lies with someone else.
Set up a responsibility matrix before the contracts are signed. The rows are the work areas: requirements, data model, integration, security, test data, acceptance testing, deployment, monitoring and maintenance. The columns are the four parties. Each cell states who carries out the work, who decides and who should be informed.
The platform vendor should be able to describe its APIs, its data model and what hosting is included. In Litium's case, hosting is included in Litium Commerce Cloud, and the ERP integrations with Monitor, Jeeves, Business Central and SAP are built and maintained by Litium or certified partners. The implementation partner should show how this is applied in your specific ERP environment, your processes and your test cases. Litium has more than 30 certified Solution Partners, and the choice of partner affects the division of responsibility as much as the choice of platform.
Three things cannot be outsourced. You own the priorities when a business requirement clashes with a technical limitation, you own the quality of the master data in the business system and you own the decisions about how you will work. A project where the customer has no named owner for those three areas ends up depending on the partner guessing right.
Apex Stainless Fasteners built its solution together with the partner Motillo and integrated it into the Bufab Group's existing systems, which meant that responsibility had to be divided across a group environment and not just a single company. BE Group, which works with the partner Exsitec, put together a working group with representatives from both Sweden and Finland, so that the decisions about what should be shared and what should be adapted per country had an owner from the start.
Questions to ask:
- Who owns each master data area on our side, by name and not just by department?
- Who approves a change to the integration logic, and who tests it?
- Who do we call when an order gets stuck, and who decides whose part of the chain it concerns?
- Who contacts the customer when an order flow is affected?
- What in the integration is covered by the platform contract, and what is covered by the partner's?
- How have you and the partner worked together on previous projects against the same business system?
The last question is the reason the platform and the partner should be evaluated together. Two vendors that each answer well on their own can still leave a gap between their contracts.
6. Plan acceptance testing and maintenance before launch
Acceptance testing is the only point at which you can reject the delivery, and it assumes that the test cases are based on your real processes. A test with three demo items and one test customer shows that the technology works. It does not show that the integration can handle your business.
Base the test cases on situations that are unusual but costly: a customer with several delivery addresses and several buyers, an order above the credit limit, an item that changes sales unit, a partial delivery, a return and a cancellation. For each test case, describe what the buyer should see, what the salesperson should see and what the business system should record. Use representative data from your own business system, because data quality is part of what is being tested.
Maintenance starts the day the project team leaves. New items, price rules, customers and order statuses will require changes, and the business system will be upgraded. Decide in advance who tests the integration after a version upgrade in either system, and who pays for the work if it stops working.
Swede-Wheel has nearly 2,000 registered customers with access to stock availability, customer-specific pricing and documentation in a customer portal integrated with Monitor, and around 40 per cent of them use these services regularly. "Connecting Litium’s platform to Monitor has simplified everything from customer support and administration for routine queries to product data management, saving us an enormous amount of time," says Emilia Haglund in customer support at Swede-Wheel.
For manufacturing companies running Monitor, there is also a route where the connection between the systems is already built. In Litium Core, the portal and the Monitor integration are preconfigured, and Monitor remains the source of truth for products, prices, stock, customers and orders. This means you do not have to start from scratch defining and developing the connection between the systems. Instead, you can focus the requirements on your business needs, your product data and the processes that are specific to you. You still need to work through the division of responsibility, the data quality in Monitor and how errors are handled, because those questions apply however the connection is built. If you run a different business system, or need your own frontend, the full platform with an implementation partner applies.
Requirements to set:
- Which of our real processes are included in acceptance testing, and who writes the test cases?
- Who tests the integration when the business system or the platform is upgraded?
- What documentation is handed over to maintenance, and in what condition?
- How are permissions and knowledge handled when the project team no longer works on the solution?
- How do we follow up that the integration still meets the requirements a year after launch?
Summary: checklist before signing an ERP integration contract
Go through the list with the platform vendor, the ERP vendor and the implementation partner before any contract is signed. Every item should have a written answer, a test case and a named owner.
- Every requirement has an owner, a priority, a test case and a definition of an approved result.
- Every data object has a named source of truth and a maximum accepted delay.
- Every flow has a described error process that distinguishes between temporary errors and data errors.
- Resending a message can be demonstrated in a test environment without creating duplicates.
- Monitoring raises alerts both for technical errors and for unusual business patterns.
- Customer service can follow an order through the whole chain without help from a developer.
- A responsibility matrix divides the work between the customer, the platform vendor, the ERP vendor and the implementation partner.
- Acceptance testing is based on real processes and data from your own business system.
- It has been decided who tests the integration at version upgrades.
A solution proposal that cannot answer these points concretely is not necessarily technically weaker, but you lack the basis for comparing it with the others. Ask for additions before you move on, and make the answers an appendix to the contract.
Frequently asked questions about ERP integration requirements
Here we answer the most common questions from B2B companies setting requirements for the connection between the business system and the e-commerce platform or customer portal ahead of a procurement or a platform replacement.
What is a requirements specification for an ERP integration?
A requirements specification for an ERP integration is a document that describes what data will move between the business system and the e-commerce platform or customer portal, which system owns it, how quickly it should be updated, what happens when something fails and who is responsible for each part. It is used to compare solution proposals and then becomes the basis for acceptance testing.
When in the procurement should the requirements specification be ready?
The requirements specification should be ready before you ask for solution proposals, so that all vendors answer the same questions. It does not need to be complete, but the source of truth per data object, the maximum accepted delay and the division of responsibility should be included. Go through it once more with the vendors you take forward before the contract is signed.
How do you write a testable real-time requirement?
State the maximum accepted delay in time, which event triggers the update and how the requirement will be tested. For example, write that a changed contract price must be visible to the logged-in customer within five minutes, and that it is tested with three items and two customers with different agreements. The words real time on their own cannot be approved or rejected.
Who should own the requirements specification, IT or the business?
The business should own the requirements and IT should own how they can be met technically. Sales, customer service, warehouse and finance know which errors cost the most, and IT knows what the business system can handle. Appoint one person responsible for the whole, and give each individual requirement a named owner in the function it affects.
What should a responsibility matrix for an ERP integration contain?
A responsibility matrix should have the work areas as rows and the parties as columns. The rows are requirements, data model, integration, security, test data, acceptance testing, deployment, monitoring and maintenance. The columns are customer, platform vendor, ERP vendor and implementation partner. Each cell states who carries out the work, who decides and who is informed.
Who is responsible for the integration when the business system is upgraded?
It should be stated in the contract, and it is one of the questions that most often goes unanswered. With a standardised integration maintained by the platform vendor or a certified partner, the responsibility for testing and adapting lies with them. With a custom-built integration, it lies with you or with the consultant who built it.
Which errors should an integration handle without manual intervention?
Temporary errors, such as a timeout or a business system that is down for maintenance, should be handled with automatic retries and a queue that is emptied when the connection is back. Data errors, such as a missing customer number or an item with the wrong unit, require someone to correct the master data. The integration should then show what is wrong and who should fix it.
What monitoring should we require after launch?
Require the monitoring to show the last successful synchronisation, the current delay and the number of messages in the queue for every flow. Add alerts on business patterns, for example zero transferred orders on a weekday or an unusual number of rejected prices. Also decide who receives the alert and how quickly it must be acknowledged.
Should the platform and the implementation partner be chosen at the same time?
Yes, they should be evaluated together. The platform determines which APIs and standard integrations are available, and the partner determines how they are applied in your ERP environment and your processes. Ask how they have worked together on previous projects against the same business system, and check that there is no gap between the platform contract and the partner's.
Is a requirements specification needed if the integration is already built?
Yes. A ready-made integration means you do not have to start from scratch defining and developing the connection between the systems, but the need for requirements remains. With a preconfigured solution such as Litium Core, where the Monitor integration is already built and Monitor remains the source of truth, you can focus the requirements specification on your business needs, your product data and the processes that are specific to you. You still need to work through the division of responsibility, data quality and how errors are handled.