Skip to content

Integration Guides

Applies to: e-Invoice · e-Way Bill · Which modules do I have?

Purpose

Give an implementation partner what they need to connect a named ERP to Complifly without a Complifly engineer — and to know exactly what to build when the ERP is not on the list.

Audience

Integration developers and implementation consultants.

Prerequisites

  • API Documentation read in full
  • Machine credentials issued for a sandbox
  • ERP-side developer effort allocated, with a named person

Steps

Read the pattern first

Every ERP integration is the same shape. The Integration Pattern documents that shape in full — flow, authentication, mapping, payloads, error handling, retry, recovery, testing, security and monitoring.

Read it before any ERP-specific page. The per-ERP pages describe only what is genuinely specific to that system; everything common lives in the pattern and is not repeated.

Step 4 of that pattern — translating your ERP's field names and value codes into NIC's — is the part every integration spends the most time on, and it has its own screen-by-screen walkthrough: Build a Mapping Template.

The guides

System Page Integration approach
SAP ECC and S/4HANA SAP ECC and S/4HANA Outbound message or middleware to mapped ingest
SAP Business One SAP Business One Add-on or service layer to mapped ingest
Dynamics 365 Business Central Dynamics 365 Business Central Extension calling mapped ingest with an identity-provider token
Tally Tally Export or connector to mapped ingest, or file upload
Oracle E-Business Suite and Fusion Oracle EBS and Fusion Integration layer to mapped ingest
Any other system Custom ERP Mapped ingest directly
Field mapping, for all of the above Build a Mapping Template Drag-and-drop mapping in the product
Government systems GSTN and NIC via a GSP Handled by Complifly; documented for understanding
Event consumers Webhooks and Events Write-back, pull or push

Verify: Which of these are productised connectors and which are integration patterns you implement is not established in this portal. Several are almost certainly the latter. Confirm before quoting effort. Recorded as assumptions F1 and F2 in the Assumptions Register.

Every integration has four moving parts

Part Owner Typical effort
Outbound — the ERP sends documents ERP developer Largest
Mapping — translating the ERP's shape Implementation consultant Moderate, but iterative
Inbound — the ERP consumes outcomes ERP developer Moderate
Operations — monitoring and exception handling Customer operations Ongoing, and consistently underestimated

The fourth is where integrations quietly fail after go-live. A document that fails validation needs a person who sees it and can act; without that, failures accumulate silently until a filing deadline exposes them.

Choosing the approach

If the ERP Then
Can call an outbound REST service Mapped ingest — the standard approach
Cannot, but can export files File upload, with a scheduled export
Has middleware in place Route through it; it usually already handles retry and monitoring
Is heavily customised Mapped ingest, with the mapping absorbing the customisation
Cannot be changed at all File upload, and accept the manual step

Validation

An integration is ready for production when:

Check Evidence
Outbound works Documents reach Complifly and are accepted
Mapping is correct The mapped payload is inspected field by field, not merely accepted
Edge cases work Export, reverse charge, multi-line, discounts, credit notes all tested
Failures are handled Each response class takes the correct path; nothing unretryable is retried
Inbound works Outcomes reach the ERP and are stored
Idempotency proven A duplicate event is processed once
Recovery proven Reconciliation after an outage restores agreement between systems
Monitoring live Someone is alerted when the integration stops
A person owns exceptions Named, with a defined process
Documented The customer can operate it without the implementer

Troubleshooting

Symptom Cause Action
Integration works in testing, fails on real documents Testing used cleaned samples Use raw ERP output
Works for weeks, then a wave of failures An edge case appearing for the first time — a first export, a first credit note Test edge cases before go-live, not after
ERP and Complifly disagree on what was processed No reconciliation Build the reconciliation described in The Integration Pattern
Failures accumulate unnoticed Nobody owns exceptions Assign an owner before go-live
The integration breaks after an upgrade It uses application endpoints rather than contracts See Endpoint Index