ERP integration services
ERP integration services for purchase requests that need a controlled handoff
Turn an approved purchase request into a reviewable ERP draft without quietly granting permission to release, receive or post it.
Bring a redacted request, its approval record and the corresponding ERP document. We can use them to define the engineering boundary and identify the ERP expertise needed before committing to implementation.
The first scope is one lifecycle: a requester submits a purchase, the right people approve a specific revision, and the ERP receives a draft tied to that decision. Changes and cancellations remain visible after creation.
01
A draft order is not the end of the approval problem
Procurement may collect supplier quotations in email while a budget owner approves an amount in another tool. Someone then creates the ERP document. The document exists, but the connection between the selected supplier, buying company, approved currency and latest request revision is hard to inspect.
The question is not simply whether the fields can be copied. It is whether the document still represents the purchase that was authorized, and what must happen when that purchase changes.
Start by checking whether the ERP's native requisition and approval workflow already solves this. A separate application can make the process worse if it creates a second approval authority. Custom integration is worth considering when a necessary upstream workflow remains outside the ERP and its boundary can be defined precisely.
02
Agree who has authority over the purchase
This proposed authority map is a starting point for review, not a universal accounting policy.
| Decision | Proposed authority | Boundary the integration must preserve |
|---|---|---|
| Supplier | Procurement selects; ERP administrator validates the master record | Map the approved supplier to the correct company-specific record; never resolve by display name alone |
| Buying legal entity | Finance approves the entity-to-ERP-company mapping | Do not silently move a request to another company when a mapping fails |
| Transaction currency | Finance defines permitted currency and conversion rules | No silent substitution when supplier defaults differ from the approved currency |
| Amount, lines and approval revision | Approver authorized under the customer's policy | An approval identifies the exact revision and relevant commercial fields |
| ERP draft identity and current state | ERP is authoritative after creation | Preserve the destination identity and detect later ERP edits before applying source changes |
| Release, receipt, invoice and posting | Authorized ERP workflow and business owners | Draft creation is not permission to perform downstream actions |
The administrator must confirm that the actual API, permissions and installed workflows can enforce these boundaries. A checkbox in an upstream application does not establish that they can.
03
Scope the lifecycle before choosing the connector
Use a request identity and revision to connect the approval record to the ERP draft. Record the supplier mapping, buying company, currency and line-level commercial fields used for that revision. Return the ERP document identity and its observed state to the source.
For this initial scope, upstream approval authorizes submission for ERP review. It does not automatically replace any required ERP approval. The destination may call its editable record Open rather than Draft. Confirm that state and any creation-triggered automation before enabling writes.
The proposed integration stops at a matched, reviewable document. Approval, release, sending to a supplier, receipt, invoice and posting remain governed separately. If the business wants to automate any of those transitions, add an explicit scope, permission and acceptance test for each.
As one concrete example, Microsoft's purchase-order API reference documents creation separately from a receive-and-invoice action. This illustrates why access to a document endpoint should not be treated as a mandate to execute every available action. It does not establish our credentials or the permissions available in your installation.
Source request
- Source request revision
- Approval evidence for that revision
- Submit for ERP review
Request identity and revision ↔ ERP document identity and observed state
ERP destination
Editable document
STOP: initial integration scope
Authorized ERP approval/release
Separately governed downstream authority
Receipt/invoice/posting
Separately governed downstream authority
Source change or cancellation → authorized review. Draft creation does not bypass ERP approval, release, receipt, invoice or posting authority.
04
Decide what happens after someone changes their mind
A source request does not become authoritative over every later ERP state merely because it created the first draft.
| Situation after creation | Proposed handling for this bounded scope |
|---|---|
| Quantity or amount changes while the ERP draft is untouched | Hold synchronization, create a new source revision and obtain the approvals required by policy; apply only through a supported, validated edit path |
| Supplier, buying company or currency changes | Require procurement/finance review; do not automatically move or replace the existing document |
| An ERP user edits the draft independently | Raise a revision conflict with both records visible; no last-write-wins overwrite |
| Source request is cancelled | Mark cancellation requested, identify the destination state and route to the authorized ERP owner; acknowledge cancellation only after its business disposition is recorded |
| ERP document is awaiting approval or has been released | Stop source-driven edits and use the ERP's authorized change process |
| Goods have been received or an invoice posted | Escalate for the applicable correction process; do not delete or recreate to simulate cancellation |
Cancellation of an upstream request and cancellation of an ERP approval are different events. Neither proves that a supplier commitment or accounting entry has been reversed.
Microsoft's approval-workflow documentation describes cancelling an approval process, changing the document and requesting approval again. Its release and reopen guidance also explains that reopening permits changes and that warehouse handling can restrict them. These are examples of platform rules to inspect, not a cross-ERP implementation recipe.
05
Accept the business boundary with finance and the ERP administrator
Use synthetic requests in a sandbox. Test the boundary before expanding the number of suppliers, companies or transaction types.
| Review exercise | Required evidence | Acceptance owner |
|---|---|---|
| Same supplier name exists in two companies | Draft uses the approved supplier identifier in the approved destination company | Procurement and ERP administrator |
| Supplier default currency differs from approval | Mismatch is rejected or resolved under an explicit approved rule; no silent currency change | Finance |
| Revision 3 is approved but revision 4 changes the amount | Revision 3 approval cannot authorize revision 4 submission or update | Approval owner |
| Request changes after an ERP user edits the draft | Conflict remains visible and no approved ERP edit is overwritten | Procurement and ERP administrator |
| Source cancellation arrives after release or receipt | Cancellation remains pending until an authorized disposition is evidenced; no automatic delete/recreate | Procurement and finance |
| Integration identity tries a downstream action | Permissions or another verified control enforce the agreed action boundary | ERP administrator |
Keep request revision, approval evidence, destination document identity, relevant ERP state and reviewer decision together. The finance owner accepts the commercial authority rules. The administrator accepts the enforceable platform behavior and permission boundary. The engineering team supplies the mapping, transition logic and test evidence.
If the platform cannot separate the required actions or expose enough state to resolve conflicts, record that limitation before quoting an automated workflow. A manual review boundary may be necessary.
06
What a bounded engineering proposal should deliver
The proposal should specify one source request type, one destination document type and the permitted company/supplier scope. Include the authority map, revision and cancellation rules, supported-interface findings and a jointly reviewed acceptance record.
Estimate ongoing work as well as initial development: supplier mapping maintenance, changed approval policies, ERP upgrades, conflict handling and ownership of unresolved requests. A connector that can copy fields may still need configuration or operating controls for this lifecycle. Test the existing product against these requirements before commissioning a replacement.
Bring the people who own procurement approval, finance policy and ERP administration into the scope discussion. Platform-specific delivery depends on validated access, supported interfaces and qualified functional expertise. Before a delivery commitment, confirm the functional lead, ERP administrator, supported interfaces and responsibilities for approval configuration. The engineering scope covers the application boundary around the ERP. ERP replacement, accounting design and tax advice require separate expertise.
