Quoting ERP interfaces: clarify data ownership before the proposal

An ERP enquiry about connecting systems can lead to very different services. Perhaps a webshop should transfer orders. Perhaps changed product information should flow back. Your contact might also expect stock levels and delivery messages from the same connection. Your proposal therefore needs a description of each handover. This lets the customer recognise the workflow they would commission, while your team prepares a defined scope. A list of application names does not yet answer that question.

This guide is for ERP providers and implementation partners. You decide whether a connection can already be quoted or first needs focused clarification with the customer and the other system partners. These questions belong to your own sales work; they do not describe extra fields supplied with a lead. All examples are explicitly fictional and contain no personal customer data. Choose technical methods and make product performance commitments only after examining the actual products, versions and approved environment.

Start with a completed handover

Ask the customer to describe one handover from beginning to end. An incoming webshop order is a useful starting point: where does it originate, what information does the ERP need, and how will sales later recognise that it is ready for further work? Record the desired end state in the employees’ language. “The order is ready for business review” is more precise than “the shop and ERP are connected”. You also discover whether automatic onward processing is part of the requested scope at all.

Then follow the reverse journey. What information must return for the shop to show the appropriate status? A received order, a confirmed delivery date and a dispatched shipment are different events. Discussing these distinctions openly lets your contact choose the feedback that matters. Give each additional direction its own entry. You can then see whether an apparently single interface contains several business tasks and which ones belong in the first proposal.

Establish where information is maintained authoritatively

Ask which system is authoritative for each relevant data category. Who creates product numbers, who changes descriptions, and where is a delivery address corrected for an individual order? The answer may differ by category. Avoid writing “ERP is authoritative” when the customer has only described product maintenance. Your proposal becomes clearer when it specifies which information should come from which system and who assesses changes from a business perspective.

Consider conflicting changes too. In a fictional case, an order address was changed in the shop while an employee entered a different address in the ERP. Ask which version should apply to this order and who decides the conflict. An automatic rule can only be assessed once the business decision is understood. You do not need a real address file for this. An invented description is enough initially to expose the conflict and identify the responsible role.

Distinguish data transport from business outcomes

A transferred message does not answer every operational question. Clarify which confirmation the customer needs: has the message arrived, has its content been accepted, or has the resulting order received business approval? Those states can have different consequences for the workflow. Ask about the next human action. Sales might need to review a transaction, while the warehouse should act only after separate approval. Include that distinction in the description.

Write a simple test case and expected observation for each handover. A fictional webshop order contains a known product and an explicitly invented delivery address. The ERP should display the order for review; a subsequent delivery commitment remains outside this case. The customer can assess the agreed state without assuming comprehensive delivery automation. Discuss a second case involving an unknown product. A visible request for clarification may be the desired result, if it fits the confirmed workflow.

Define freshness through the customer’s work

Ask when a change is needed before proposing a transfer technology. Must sales know the new status before its next commitment, or is agreed later processing sufficient? Which work step would wait if processing were delayed? These questions reveal the actual need. “Automatic” implies neither a particular speed nor uninterrupted availability. Both require separate assessment and a service description appropriate to the solution.

Check that desired freshness fits the existing working method. If an employee releases data only after manual approval, faster technical polling alone will not resolve the issue. Ask whether that approval should deliberately remain. If so, it belongs in the handover sequence. If the customer wants to change this step, record a separate business decision. Your team can investigate the technical part without inadvertently taking responsibility for an unresolved business process.

Include clarification and reprocessing

Discuss what employees should see when a handover cannot be processed for business reasons. Who receives the notice, what information do they need, and how do they recognise that the issue has been resolved? Stay with the business case. A missing product might require a decision from product maintenance; an incomplete order belongs to a different role. A technical notification becomes useful when someone can derive the appropriate next action from it.

Ask about retransmitting the same transaction too. Should an existing order be recognised, updated or presented for review? Which identifier is actually available? Your sales team should not promise prevention of duplicate orders before the specialists have assessed the intended method. The proposal can distinguish the desired state from the prerequisite still awaiting confirmation. The customer then sees what is established and which investigation must precede implementation.

Involve the relevant system partners purposefully

A connection needs information from both sides. Ask the customer for the responsible contact for the connected system and the appropriate product documentation. Clarify who can explain the actual version, available access options and a suitable testing opportunity. You do not need credentials in a general sales note for this first discussion. What matters initially is whether the responsible people can jointly assess the intended handovers from both business and technical perspectives.

Allocate the participants’ services explicitly. Your team may handle the ERP side while the shop service provider performs another task. Ask who coordinates the joint test and follows up unresolved questions. Merely naming the partner in a proposal does not explain that responsibility. Identify necessary customer contributions too, such as deciding a product mapping. The customer can then compare proposals with different responsibility boundaries and identify missing steps before commissioning the work.

Choose between a proposal and preliminary clarification

Determine which information your sales team can leave pending for a dependable proposal and which gaps leave the scope undefined. A missing contact is different from an unresolved transfer direction. If central prerequisites are unknown, propose a specifically bounded analysis, provided your company actually offers it. Describe its result, such as agreed handovers and open technical prerequisites. Do not invent a fixed price, completion period or an implementation contract that would automatically follow.

Summarise the established points in a short service description: initiating event, data category, authoritative source, direction, expected end state, handling of questions and responsible people. Add explicitly excluded handovers. The customer should recognise whether you are considering orders alone or also stock and delivery messages. For pending prerequisites, name the precise confirmation required. “Connecting all relevant systems” cannot replace this shared description, because each participant might interpret it differently.

Test the scope with a counterexample

Imagine an explicitly fictional retailer who wants to import orders from a webshop. The initial scope makes incoming orders available for review. Later, the customer asks for automatic feedback about partial deliveries. Your team treats this as an additional handover with its own end state and responsibility. The original decision remains understandable. An extension can be discussed deliberately rather than continually adding services to a term already in use.

Review the same scope from the perspective of a colleague who missed the conversation. Can they explain where an order originates, who resolves conflicting changes and how the customer recognises the agreed processing? If they need assumptions, add precisely the missing statement. A longer application list does little here. Your result is a usable proposal boundary: either sufficiently described from a business perspective or paired with a clearly identified clarification that the customer can consciously commission.

Check meanings and changes to the same transaction

Compare the meaning of the required information too. A quantity may refer to individual items, cartons or another agreed unit. A product number may have a different mapping in the shop and ERP. Use invented examples to ask which unit and mapping apply to this workflow. A technically populated value is ready for business assessment only when both sides understand it in the same way and can follow the mapping.

Then include a change to an order already transferred. For example, the customer reduces a quantity after the ERP transaction has been created. Ask up to which processing stage that change is intended and who should review it. A change before review may need different treatment from one after execution starts. Do not infer a technical implementation yet. First record the desired business response to each state separately.

Consider cancellation too. What should remain visible in both systems when an order is withdrawn? Who may make that decision, and which employee needs to know afterwards? Review the desired workflow without turning it into a general legal rule. For your proposal decision, establish whether this case belongs in the agreed scope. If it will be examined later, state that boundary explicitly in the shared description.

Ask your contact to explain these cases in their own words. Distinguishing receipt, change and cancellation lets your team investigate technical feasibility for each case purposefully. If a meaning remains unclear, that precise mapping is the next question. This creates a usable working basis for the other system partner too, who previously knew only the general wish for a connection.

Source context

For Dynamics 365 integrations, Microsoft recommends aligning cross-system process requirements with business goals. Its integration overview provides only that context here; it does not demonstrate an interface capability in your product.

Prepare new ERP conversations

With ERP leads from webRichtung, you can reach businesses in Germany looking for ERP proposals. The enquiry supplies process area, current system situation, planning stage, location and contact details. You clarify specific products and interfaces yourself. Register your business and prepare the lead order in webRichtung Customer; you see the current price before placing a binding order.