Integrations: how it works and what to require
Proconomy coexists with your existing systems of record. It reads approved master and transaction context from ERP and adjacent systems, executes governed procurement work around them, and writes approved outcomes back. Connections are made through governed APIs with monitored data flows and explicit failure handling.
What is read. And what is written back.
Twenty-four objects and systems, sorted by direction of travel.
Read from your systems
- Supplier master and banking records
- Material and service master data
- Cost centres, GL accounts and budgets
- Open purchase orders and receipts
- Invoice and payment status
- Organisational and entity structure
Written back on approval
- Requisitions with approved values
- Purchase orders against the approved outcome
- Approved supplier records
- Contract references against orders
- Goods receipt and service entry confirmation
- Invoice match outcomes
Adjacent systems
- PLM for part and engineering change context
- QMS for the formal quality record
- Finance systems for payment execution
- Identity providers for single sign-on
- Email and messaging for intake and notification
- Document and eSign platforms
Multi-system reality
- Several ERP instances across entities
- Different ERP vendors after an acquisition
- A legacy system nobody will replace this year
- Entities on different release versions
- Partial data availability in one entity
- A phased connection rather than all at once
Coexistence, not replacement. And failure that surfaces.
Seven properties, and silent retry is the wrong answer to all of them.
| Mechanism | What it has to do |
|---|---|
| Coexistence, not replacement | Proconomy governs procurement execution. The ERP continues to hold the transaction, which is why this does not become a core replacement programme. |
| Approved outcomes only | Nothing is written until it has passed the approval your policy requires. The record system never receives work in progress. |
| Monitored synchronisation | Write-back success and failure are both visible. Silent failure is the defect that costs most and surfaces latest, so it is surfaced rather than retried invisibly. |
| Controlled retry and surfacing | Failures are raised to a person with the reason, not swallowed by an automatic retry loop. |
| Multiple instances natively | Several ERP instances across entities without consolidating them first, which matters because consolidation is usually the project that never starts. |
| Scoped per integration | Systems, objects and field mappings confirmed with your architects during scoping, and the scope is written down before anything is built. |
| Phased connection | One workflow and one entity can be connected and producing evidence while the rest is still being scoped. |
A description of what the practice requires, not a feature list.
Same connectors. Different adjacent systems.
What else has to be read, by industry.
Automotive
PLM part and change data read alongside ERP, because sourcing decisions follow engineering change.
Medical devices
QMS remains the formal quality record; Proconomy governs the procurement work around it.
Industrial equipment
Bills of material and product configuration stay in PLM and ERP, read for context rather than duplicated.
Multi-entity groups
Several ERP instances connected in parallel, with entity structure preserved rather than flattened.
Five questions. Get the objects list in writing.
Before signature, not after.
- Ask what happens when write-back fails. Silent retry is the wrong answer.
- Ask exactly which objects are written and which are only read. Get it in writing before signature.
- Describe your multi-ERP reality and ask them to scope it in the session rather than afterwards.
- Ask whether the ERP remains the system of record, and what that means precisely in their architecture.
- Ask what can be connected first, producing evidence, before the full scope is built.
Definitions. Asked and answered.
Proconomy coexists with your ERP and writes approved outcomes back to it. Which systems, which objects and which field mappings is a conversation with your architects during scoping — bring the integration constraints you already know about and we will size them in that session rather than after signature.
Neither. The ERP remains the system of record for the transaction. Proconomy governs the execution around it and writes the approved result back.
It is surfaced as an exception with the affected transaction, the error and the retry position shown together. Retries are controlled so they do not create duplicate records.
Yes, where that context improves the procurement decision — part and specification data, quality status and financial commitments. Scope is defined per integration during implementation.
Through governed APIs with scoped, permissioned access that follows the same role-based model as the rest of the platform, with a retained event history for audit.
No. Customers commonly begin with one workflow and the connections that workflow needs, then extend. The integration foundation is designed for modular adoption.
A system of record is the authoritative source for a given data set — in procurement, usually the ERP for transactions, supplier master and financial postings. Introducing a second system that also claims authority over the same data creates reconciliation work and eventually disagreement.
No. The ERP remains the system of record for the transaction. Proconomy governs the procurement work that produces an approved outcome and writes that outcome back, with success and failure both monitored.
Write-back is the creation or update of records in the system of record from an external application — a requisition, purchase order or supplier record created from an approved procurement outcome. The important properties are that only approved outcomes are written and that failures are surfaced rather than hidden.
Yes. Multiple instances and multiple vendors across entities are the normal case in groups that have grown by acquisition, and the design assumes it rather than requiring consolidation first.