Getting extracted invoice data into an ERP sounds like a solved problem. In practice, ERP integration is where document automation projects spend 40-60% of their implementation time. The reason isn't fundamental technical complexity — it's the number of configuration decisions that have to be made and validated against each customer's specific ERP setup, data model, and business rules.
We've connected Fieldiq to SAP S/4HANA, Oracle NetSuite, Microsoft Dynamics 365, QuickBooks, Workday, and a handful of others. The integration pattern chosen is not a technical preference — it's a function of the ERP's API capabilities, the customer's IT constraints, and how the AP workflow needs to operate. This post covers the three patterns we implement most often, when each is appropriate, and the data mapping considerations for each.
Pattern 1: Direct API Push
Direct API push is the cleanest integration model: after extraction and exception review, Fieldiq posts the structured invoice record directly to the ERP's vendor invoice endpoint via REST API. The ERP returns a confirmation (invoice ID, status), which we store as the integration receipt.
The request body for a NetSuite vendor bill creation looks something like this:
POST /services/rest/record/v1/vendorbill
Authorization: Bearer {oauth_token}
Content-Type: application/json
{
"entity": { "id": "V-10482" },
"tranDate": "2024-12-09",
"duedate": "2025-01-08",
"currency": { "id": "USD" },
"memo": "Fieldiq extraction ext_7f3a2b1c",
"item": [
{
"item": { "id": "ITEM-BRG-6205" },
"quantity": 24,
"rate": 18.75,
"amount": 450.00
}
]
}
When to use it: Direct API push is appropriate when the ERP has a stable, accessible vendor invoice creation API — which NetSuite does, and which Dynamics 365 Business Central does well. SAP S/4HANA also supports this via OData services, though the authentication setup is more involved (SAP's OAuth 2.0 implementation requires service-specific scope configuration that usually takes 2-4 days to work through with an SAP Basis admin).
The mapping challenge: Every ERP uses different internal IDs for vendors, items, and GL accounts. Our extraction produces vendor_name as a string; the ERP needs an internal vendor ID. We maintain a vendor mapping table that translates between extracted vendor names (and their variants) and the ERP's internal entity IDs. This table is built during implementation using your vendor master export and maintained as new vendors are added.
GL coding: Direct API push requires GL account assignment before the push. We don't assign GL codes — that's the customer's business logic. The typical implementation has the AP team or ERP's own default account logic handle GL assignment in the exception review step, before Fieldiq pushes the record. For invoices where GL is predetermined by vendor (common in procurement operations), a GL default rule in the ERP handles it post-push.
Pattern 2: File Drop and Polling
File drop (sometimes called "file-based integration") means Fieldiq writes structured output files — typically CSV or XML — to a designated SFTP location or network share, and the ERP's import process picks them up on a schedule. No real-time API calls; the ERP polls for new files and ingests them.
This pattern is less elegant architecturally, but it's the right choice in several scenarios:
- Legacy ERP with no REST API: Older SAP ECC environments, some Epicor versions, legacy JD Edwards — these don't have modern REST APIs. They accept flat-file imports via SFTP or network share, and that's the integration surface available.
- IT policy restrictions on external API access: Some enterprise IT teams don't allow external systems to call their ERP APIs directly, even from approved vendors. File drop via SFTP with IP allowlisting is often an acceptable alternative.
- Batch processing preference: Some AP teams prefer to run invoice imports once or twice daily rather than continuously. File drop with scheduled polling supports this workflow cleanly.
The output file format depends on what the ERP accepts. SAP supports IDOC (legacy) and CSV import via LSMW or BAPI batch inputs. NetSuite supports CSV import via its Import Assistant. Dynamics 365 Finance supports ODATA batch and flat-file import via Data Management Framework.
The operational downside of file drop: error reporting is delayed and indirect. If a record fails the ERP's import validation, the error typically appears in an import log that someone has to monitor. We build a feedback loop: the ERP's import error file gets written back to a monitored location, Fieldiq reads it, and failures are surfaced in the exception queue with the original extracted record linked. Without that loop, failed imports disappear silently — which is the same problem OCR+regex had.
Pattern 3: Webhook-Triggered Push
The webhook pattern inverts the direction of notification: instead of Fieldiq pushing to the ERP directly, Fieldiq emits a webhook event when extraction and review are complete, and a middleware layer (the customer's iPaaS, an Azure Logic App, or a custom integration service) picks up the event and handles the ERP write.
POST https://hooks.customer-integration.example.com/fieldiq
Content-Type: application/json
X-Fieldiq-Signature: sha256={hmac_signature}
{
"event": "extraction.reviewed",
"extraction_id": "ext_7f3a2b1c",
"document_type": "invoice",
"status": "ready_to_push",
"fields_url": "https://api.fieldiqx.com/v1/extractions/ext_7f3a2b1c/fields",
"timestamp": "2024-12-09T14:22:31Z"
}
The middleware then calls the Fieldiq API to retrieve the full field payload and pushes it to the ERP using whatever integration logic it already has configured. This pattern is most common when:
- The customer already has an iPaaS: If an organization has MuleSoft, Boomi, Azure Integration Services, or similar already handling their ERP integrations, it often makes more sense to add Fieldiq as a data source in that existing platform rather than building a separate direct connection. The iPaaS team knows their ERP integration; we're just a new input.
- Complex transformation logic: If extracted data needs significant transformation before it fits the ERP schema — multi-entity GL routing, complex cost center assignment rules, currency conversion with custom rates — the webhook pattern lets that logic live in a dedicated integration layer where it's easier to maintain and test.
- Multi-ERP environments: Companies running multiple ERP instances (e.g., SAP for manufacturing, NetSuite for a subsidiary) can fan out from a single Fieldiq webhook to multiple targets with appropriate routing logic in the middleware.
Choosing the Right Pattern: Decision Framework
The simplest decision framework:
| Condition | Recommended Pattern |
|---|---|
| ERP has modern REST API, IT allows external API calls | Direct API push |
| Legacy ERP or IT disallows direct external API access | File drop + polling |
| Customer has iPaaS or complex transformation requirements | Webhook-triggered |
| Batch AP processing workflow (not real-time) | File drop + polling or webhook with batch accumulation |
| Multi-ERP environment with different systems per entity | Webhook-triggered with routing middleware |
What We've Learned About Implementation Time
The extraction side of an implementation typically takes 1-2 weeks including exception threshold calibration and document quality review. The ERP integration side typically takes 3-6 weeks — dominated by vendor master mapping, GL account configuration, and the back-and-forth with the customer's ERP admin or IT team to configure API access or SFTP credentials.
We're not saying 6 weeks is acceptable or expected — several of our integrations have gone live faster. The variance is almost entirely driven by how quickly we get access to the ERP environment for testing and how responsive the customer's ERP admin is. When we have sandbox access and a responsive IT contact, 2-3 weeks for direct API integration is achievable.
The one thing we consistently tell teams before starting: get your vendor master export ready. Mapping extracted vendor names to ERP internal IDs is the most time-consuming part of any integration, and it requires the customer's data, not ours. If you can have a clean vendor master export ready at kickoff, implementation moves significantly faster.