ERP Integration Services in India

Why Is Integrating an ERP Harder Than Any Other Integration?

Every integration project has the same surface story. Two systems, one needs data from the other, write some code in between. ERP work looks like that on the estimate and behaves like something else entirely once you start.

The first difference is that the ERP is not a database with an API in front of it. When you post an invoice, the system derives tax, checks credit limits, validates the account assignment, hits the currency table, updates open item balances, writes to the general ledger, and creates entries in half a dozen tables that must agree with each other for the rest of the company's life. That is not a row insert. It is a business transaction with rules that a controller signed off on, and the interface you are calling exists to run those rules rather than to store your payload.

The second difference is the consequence of getting it wrong. If a marketing integration double-writes a contact, someone deletes one. If a finance integration double-posts a supplier invoice, you have paid twice, the payment run has already gone to the bank, and the correction is a documented reversal that an auditor will read next year. There is no delete in an ERP worth using. Everything you do wrong stays visible, which is exactly why the systems are built the way they are.

The third difference is organisational. The API you want to call belongs to a team that does not report to you, in a system whose change process is measured in weeks, running on an environment that finance has booked for close testing. In most other integration work the two ends are both yours. Here, one end is a shared corporate asset with its own governance, its own release calendar and its own idea of what an emergency is.

The fourth is time. ERP interfaces are built around a financial calendar, not a request-response loop. Periods open and close. Batches run in windows. A document created at one minute to midnight on the last day of a quarter belongs to that quarter even if it arrives four minutes later. Ignore the calendar and your integration will work fine for three weeks a month and cause a fight in the fourth.

None of this makes the work impossible. It makes it a different discipline from wiring two SaaS products together with webhooks, and the teams that get burned are usually the ones who priced it as the second thing.

Master Data and the Fight Over the Single Source of Truth

Most failed ERP integrations are not technical failures. They are unresolved arguments about who owns a record, discovered late and encoded by accident.

The argument nobody has out loud

Sales believes the CRM owns the customer, because that is where the relationship starts. Finance believes the ERP owns the customer, because that is where the credit limit, the tax registration and the payment terms live. Operations believes the warehouse system owns the item, because that is where the physical thing is. Everyone is right about their own field and wrong about the record. If you build the integration before someone decides, you will end up with a bidirectional sync where the last writer wins, and the last writer is whichever job happened to run second.

Ownership is per field, not per record

The workable answer is almost always split. The CRM owns the trading name, the contacts and the sales territory. The ERP owns the payment terms, the credit limit, the tax classification and the account group. Each field has exactly one authoring system and the other side is read only for it, enforced in the integration rather than in a policy document. When a user does change a read only field in the wrong system, the integration overwrites it on the next run and the user learns. That sounds harsh and is much kinder than silent divergence.

Identity, and who mints the key

The ERP has its own number ranges and will assign its own internal identifier whether you like it or not. Your other systems have theirs. The mapping between them is a real artifact that has to be stored, backed up and reconciled, not derived on the fly from a name match. We keep an explicit cross reference table with the external system, the external key, the ERP key and the date it was established, and we make the external key visible in the ERP record so a human troubleshooting at 2am can find it without a database query.

Duplicates already exist and will keep arriving

By the time you integrate, both systems already contain the same customer under two spellings, one with a trailing full stop and one without. Deciding the survivorship rules is a business exercise: which system wins per field, what confidence threshold justifies an automatic merge, and which cases go to a human queue. Automatic merging above a low confidence threshold is how you end up posting an invoice to the wrong legal entity, which is a bad day for everyone.

Chart of accounts and the mapping that outlives the project

Anything posting to the general ledger needs a mapping from your source system's concept to an account, a cost centre, a profit centre and often a project or a segment combination. That mapping is business logic, it changes when finance restructures, and it must not be buried in code. We hold it as configuration that finance can review, with a change history, because the request to add a new cost centre will arrive on a Friday during close and you do not want it to require a release.

Hierarchies and the things that do not map cleanly

Company codes, legal entities, subsidiaries, business units, plants, storage locations, warehouses, sales organisations. Source systems usually have a flatter model than the ERP, so one field on your side has to explode into three on theirs, using rules that come out of a conversation with finance rather than out of the data. Intercompany flows are the sharpest version of this, because the same physical movement becomes two postings in two entities that must reconcile to zero.

SAP Integration: S/4HANA, OData, BAPI, IDoc and Integration Suite

SAP has the widest set of integration options and the steepest learning curve. Which one is right depends on whether you are on S/4HANA or an older Business Suite release, whether it is on premise or cloud, and what the flow actually is.

OData and the SAP Gateway route

S/4HANA exposes a large catalogue of OData services, both V2 and V4, published through SAP Gateway and documented in SAP's public API hub. This is the pleasant option: an HTTP endpoint, a metadata document, filtering and paging. The caveats are that the standard service may not expose the field you need, extending it means ABAP work by someone with a developer key, and OData is a poor fit for high volume posting. For read access and moderate transactional work it is where we start.

RFC and BAPIs, and the commit nobody documents

BAPIs are RFC-enabled function modules with a deliberately stable interface, and there is one for almost every business object. Two things surprise every new team. First, most BAPIs do not commit on their own, so you call the BAPI and then call the commit function explicitly, and if you forget, everything appears to work and nothing is saved. Second, errors do not throw. They come back in a return table with a message type, so a caller that ignores the return table will treat a failed post as a success. We wrap every BAPI call with return table inspection and an explicit commit or rollback decision, and we test the rollback path rather than assuming it.

IDocs, and what the status numbers actually mean

IDocs remain the workhorse for asynchronous document exchange, with standard types for orders, invoices, material master, customer master and much else. The operational reality is that IDocs fail quietly. A message sits in an error status in the monitor and nothing else happens unless somebody looks. We instrument this properly: statuses that indicate a posting failure are pulled into your alerting with the failing segment and field, retries are controlled rather than blind, and reprocessing is a runbook step with an owner rather than a habit one person developed. Partner profiles, ports and process codes all need to exist on the SAP side before anything flows, which is ERP team work and needs booking in.

SAP Integration Suite, Cloud Connector and the middleware question

If you already own SAP Integration Suite, we build the flows there. It handles the connectivity, the mapping and the monitoring, and Cloud Connector is the standard way to reach an on-premise system from a cloud tenant without opening inbound ports. If you do not own it, buying it purely for two interfaces is usually poor value, and a small well-tested service in your own cloud will do the job with less licensing and fewer specialists required to change it. We will say which way we would go and why, including when the answer is that you should not add middleware at all.

Custom fields, Z objects and the upgrade tax

Almost every SAP estate has custom fields on standard structures and often custom IDoc segments. Integrations that depend on them are fine until an upgrade or a conversion project touches them. We keep an explicit dependency register naming every custom object the integration reads or writes, so that when the upgrade programme starts, the impact assessment takes an hour instead of a fortnight of archaeology.

Licensing is a design input, not a footnote

How SAP counts access from external systems has real commercial consequences at volume, and the answer depends on your specific agreement. This is not something to discover after you have built a chatty integration. Raise the design with your SAP account team or licensing advisor early, and treat their answer as a constraint on the architecture. We are engineers, not your licensing advisors, and we will not guess on your behalf.

NetSuite Integration: SuiteTalk, RESTlets, SuiteQL and Governance Limits

NetSuite is the ERP we see most often behind fast-growing ecommerce and services businesses, and it has a specific failure mode that catches almost everyone: the platform meters your scripts, and the meter runs out exactly when volume is highest.

The interface options, and what each is for

SuiteTalk comes in a long-standing SOAP flavour with dated versions and a REST flavour that supports SuiteQL for querying. RESTlets are custom endpoints you write in SuiteScript, which is the right choice when the standard record operations do not match your business process and you want the logic to run inside NetSuite rather than in your middleware. Saved searches and the analytics connectivity option are the sane way to pull reporting volumes out. Picking between them is mostly about whether you need custom logic on the NetSuite side and how much data moves.

Governance is the design constraint

Every SuiteScript operation consumes usage units, and each script type gets a budget per execution. Exceed it and the script stops, mid-job, with work half done. The numbers are published by NetSuite and do change, so we read the current governance table rather than trusting anything written in a blog post. What matters architecturally is that you design for it: process in chunks with a resumable cursor, use map/reduce for anything large because it is built for exactly this, keep RESTlets small and let the middleware own orchestration, and never write a script whose unit cost scales with an unbounded record count. Add account concurrency limits on top, and a naive parallel loader will start getting rejected under load.

Authentication and the moving target

Token-based authentication and OAuth 2.0 are the supported routes and the older simpler methods have been retired. Roles and permissions in NetSuite are granular and integrations frequently fail on a permission nobody thought about, in a way that produces an unhelpful error. We provision a dedicated integration role with least privilege, document exactly which permissions it needs and why, and keep that list current, because the alternative is somebody granting administrator to make a ticket go away.

Sandboxes are a paid, scarce resource

NetSuite sandboxes are licensed separately, refreshes take real time, and the one your company owns is usually booked by whoever is doing a configuration project. This is the single biggest practical constraint on NetSuite integration work and it needs to be in the plan on day one, with agreed booking windows, rather than discovered when the first posting test is due.

Where the business logic goes

The recurring architectural decision is whether transformation lives in SuiteScript inside NetSuite or in your integration layer outside it. Inside is closer to the data and can use the record model directly. Outside is easier to test, easier to version control properly, easier to staff and does not consume governance units. Our default is outside, with SuiteScript reserved for things that genuinely must run in the platform, such as user event validation. Every line of SuiteScript you write is a line somebody has to maintain in a language with a small hiring pool.

Financial Period Close and Why Your Integration Has to Respect It

This is the section that separates people who have integrated an ERP from people who have integrated a database. The financial calendar is not background information. It is a hard constraint that your interface has to model.

Periods close, and closed means closed

At the end of a month, quarter or year, finance closes the posting period. After that, the ERP will refuse a posting dated inside it. This is not a bug to work around, it is the control that makes the reported numbers mean something. Your integration will therefore get rejections it never sees for three weeks and then hits every month, and if the design treats a rejection as a transient failure it will retry into a closed period forever.

Three different dates, and they are not the same date

A document has a document date, which is when the business event happened. It has a posting date, which determines the period it lands in. It has an entry date, which is when it hit the system. A transaction that occurred at 23:58 on the last day of the period and arrives at 00:03 belongs to the old period by document date and would land in the new one if you let the ERP default it. Getting this wrong shifts revenue between periods, which is the kind of error that gets escalated well above your level. We carry all three dates explicitly through the interface and never let the target system default the one that matters.

Freeze windows and held traffic

Finance will usually want quiet during the close run. That means the integration needs a supported way to stop accepting postings, hold them durably, and release them afterwards in the right order, without the source system either blocking or silently dropping them. Building this in from the start is a day of work. Retrofitting it during a live close is not.

Accruals and the cut-off problem

For goods received but not invoiced, or services delivered but not billed, finance needs the accrual at period end. If your integration is the thing that tells the ERP about those events, its timeliness becomes a reporting accuracy issue rather than a convenience issue. That changes the service expectation for a handful of days a month, and it is worth agreeing what those days look like before you are in one.

Year end is a bigger version of the same problem

Year end brings balance carry forward, a new fiscal year in the ERP configuration, sometimes new company codes or a restructured cost centre hierarchy, and a longer freeze. Anything in the integration that hardcodes a fiscal year, a period number or a cost centre will break, and it will break at the busiest possible time. We audit for exactly that before the first year end after go-live, and treat the first close and the first year end as planned support events with agreed cover rather than as ordinary weeks.

Transactional Consistency When the ERP Will Not Join Your Transaction

You cannot wrap your database write and an ERP posting in one atomic transaction. Distributed transaction protocols are either unavailable, unsupported by the vendor or banned by whoever runs the ERP. Accept that early and design for it, because the alternative is a system that is subtly wrong in ways that only show up at volume.

The outbox pattern, and why it is worth the extra table

Write the business change and the intent to send in the same local transaction, then have a separate process read the outbox and deliver to the ERP. If your service crashes after the write and before the send, the message is still there. If it crashes after sending and before marking it sent, it sends again, which is why the next point matters more than this one.

Idempotency has to be enforced by the ERP, not by your code

A deduplication check in your service is a race condition with extra steps. The reliable design puts a stable business reference on the document and relies on the ERP to reject the duplicate, using a field it treats as unique. Where the ERP will not enforce uniqueness on any usable field, the fallback is a check immediately before posting plus a reconciliation sweep that catches what slipped through. That is weaker, and we say so rather than pretending the problem is solved.

Compensating actions instead of rollback

When step three of a five step process fails, you cannot undo steps one and two. You post an offsetting entry, cancel a reservation, or raise a credit. Each of those is a real business operation with its own rules, and it needs designing alongside the happy path rather than being invented during an incident. We write the compensation for every multi-step flow as part of the build.

Ordering, and why it bites in ERP more than elsewhere

Masters must exist before transactions. A goods receipt cannot precede its purchase order. A payment cannot precede its invoice. Queues that parallelise for throughput will happily deliver these out of order. Partitioning by business key so that everything about one document stays in one ordered stream is usually the right answer, and it costs you some parallelism. Take the trade rather than sequencing by hope.

Eventual consistency is fine, undetected divergence is not

Nobody sensible expects the two systems to agree at every instant. What matters is that they converge, that the window is known, and that a divergence which persists past the window raises an alarm. That is the whole reason the reconciliation loop exists. Without it, eventual consistency quietly becomes permanent inconsistency, and you find out when a customer disputes an invoice.

Upgrade Cycles, Customisation Debt and Integrations That Rot

An ERP integration is not finished when it goes live. It sits on top of a platform that changes underneath it, on a schedule you influence at best.

Two very different upgrade shapes

Cloud ERPs push updates on the vendor's cadence. You get a preview or test window and a mandatory adoption date, and the changes are usually small and frequent. On-premise ERPs get infrequent, enormous, heavily planned upgrades where a year of accumulated change lands in one weekend. The first shape needs a small regression pack you can run often. The second needs the integration to be a named workstream in the upgrade programme, with its own test plan and its own sign-off, rather than a line item somebody remembers late.

Customisation is the real risk, not the version number

Standard interfaces on standard objects survive upgrades reasonably well. Interfaces that read a custom field added by a contractor in 2016, or a modified message segment, or a report whose layout somebody tweaked, are the ones that break. The mitigation is unglamorous: an explicit register of every ERP object the integration touches, marked standard or custom, with the custom entries flagged as upgrade risks. It takes a day to produce and saves a fortnight of investigation later.

Version pinning where the vendor allows it

Some ERP interfaces are versioned and let you stay on a known version while you test the next. Where that exists, use it, and put a date in the calendar for moving rather than treating pinning as a permanent solution. Pinning without a migration plan is how you end up on a version the vendor stops supporting during your busiest quarter.

Deprecation notices arrive by email to somebody who left

Vendors do announce retirement of authentication methods, API versions and interface types, and the notice usually goes to an administrator address rather than to your engineering team. We make it a named responsibility to watch the release notes for the specific interfaces in the register. It is a small amount of ongoing attention and it is the difference between a planned change and an outage.

The integration will accumulate its own debt too

Special cases pile up. One entity that needs a different tax rule, one product line with a different unit of measure, one customer whose purchase order numbers have letters in them. Each is reasonable on its own and together they turn a mapping into something only one person understands. We push those into reviewable configuration wherever we can, and where a genuine code branch is needed we make sure it is documented with the reason and the date, so the person removing it in three years knows whether they are allowed to.

Four Situations We See Repeatedly

These are composite patterns drawn from the shape of work in this space rather than named clients. They are here because the failure modes repeat, and recognising yours is more useful than a logo wall.

A direct-to-consumer brand on Shopify and NetSuite, breaking every peak

Orders sync fine at normal volume. During a sale weekend the nightly job stops halfway through, because the script exhausted its governance budget and there was no resumable cursor. Meanwhile refunds are being pushed as order deletions, which NetSuite will not accept, so a growing pile of refunds exist in Shopify and not in the ERP. The fix has three parts. Move the load to a chunked, resumable pattern designed for volume. Model a refund as a credit memo referencing the original document rather than as an undo. Add a daily reconciliation on order count and value so a divergence is caught the next morning instead of at quarter end.

A manufacturer on SAP with a new shop-floor application

Production confirmations and goods movements flow as IDocs. It works, until it does not: messages start failing on a material that was extended to a new plant without the corresponding master data, and they sit in an error status. Nobody is watching the monitor, so the first anyone knows is a stock discrepancy three weeks later, by which time hundreds of messages have accumulated and reprocessing them in the wrong order makes things worse. The fix is operational rather than clever. Failure statuses feed alerting with the failing segment and field named. Errors land in a queue with an owner. Reprocessing is ordered by document and gated on the master data being fixed first. A weekly count reconciliation between the shop-floor system and SAP proves it stays clean.

A multi-entity services business moving billing onto Oracle Fusion

The homegrown billing system knows customers and amounts. Oracle needs a ledger, a legal entity, a business unit and a complete account combination, and the derivation differs by entity. The first attempt hardcodes it, then a restructure adds two entities and the mapping is wrong for a month. On top of that, the first month end lands mid-project and postings start bouncing off a closed period. What works is holding the derivation as finance-reviewable configuration with change history, staging postings so rejects are visible and fixable rather than lost, making the scheduler period-aware so late arrivals are held rather than retried blindly, and treating the first close as a supported event with agreed cover on both sides.

A logistics business on Dynamics 365 with a third-party warehouse provider

Stock movements arrive from the provider as files at unpredictable times, sometimes twice. Without an idempotency key the same movement gets applied twice and inventory drifts. Under load the Dataverse side starts returning throttling responses, the client ignores the retry hint and hammers harder, making it worse. The corrections are straightforward once diagnosed: a stable movement reference enforced on the ERP side, a client that honours the retry hint with backoff, ordered processing partitioned by item and location, and a daily stock reconciliation against the provider's own totals rather than trusting the feed.

What Goes Wrong, and How We Handle It

No point pretending everything goes smoothly. Here is where ERP integration work actually goes sideways, and how we respond when it does.

Environment access arrives six weeks late

The single most common cause of slippage. The request goes into a change process, it needs an approval from someone on leave, and the sandbox is booked. We batch every access and environment request into week one, put dates against them, and sequence the work so that mock-based development continues while we wait. If the dates cannot be met we raise it as a schedule issue immediately rather than absorbing it silently and reporting a delay later.

The interface specification describes a system that no longer exists

The implementation-era documentation and the live system rarely agree anymore. Week one becomes an audit: we run the real interface, record what it actually does field by field, and mark every point where the old spec no longer matches reality. Your team calls each disagreement, and the corrected version becomes what we build against. That audit costs a handful of days. Skipping it costs the rework later.

Master data is not ready and nobody knew

Half the items in the source system have no equivalent in the ERP, or exist under a different code, or are not extended to the plant or subsidiary the transaction needs. This is not an integration bug and cannot be fixed by an integration. We surface it early with a gap report by count so it becomes a visible piece of work with an owner, rather than a stream of mysterious posting failures after go-live.

Two systems are both allowed to create the same record

Discovered when duplicates appear. The fix is a business decision about ownership, and the integration cannot make it. What we can do is make the consequences visible fast, propose a per-field ownership model, and hold the build until someone with the authority signs it. Building the sync first and settling ownership afterwards produces an integration that encodes an argument rather than a decision.

The volume in production is nothing like the volume in test

Governance limits, throttling, batch windows and job timeouts all behave differently at real volume, and the test environment will never show you. We design for the documented limits rather than for observed behaviour in test, load-test the transformation and queueing layers where we can, and treat the first peak after go-live as a planned event with someone watching.

A perfectly good integration gets blamed for a data problem

Common and corrosive. When the numbers do not match, the newest component gets suspected first. The defence is the reconciliation report and the correlation identifiers, because they let you demonstrate in minutes what was sent, what was accepted and what the ERP did with it. This is a large part of why we build them from day one rather than adding them when trust has already gone.

What happens when someone leaves

Engineers move on, here and everywhere else, and pretending otherwise helps nobody. What actually protects you is structural: no interface is ever known by one person alone, the dependency register and the runbook live in your repository rather than in somebody's head, and handover is written down as the work goes rather than assembled in a hurry during somebody's last week. Exactly what notice and replacement look like is set out in the MSA before the engagement starts, and we are not going to invent a figure for this page that was never agreed with you.

Where This Sits Alongside Our Other Work

ERP integration rarely arrives on its own. If the wider problem is a whole estate of point-to-point connections rather than one ERP, our enterprise integration services cover the architecture question of what middleware, if any, you should actually own. Where the system on the other end of the interface is an ageing in-house application that nobody wants to touch, the integration work and the legacy application modernisation question tend to constrain each other and are worth deciding together rather than in sequence.

If the ERP itself is moving from on-premise to a hosted or cloud deployment, the interface layer has to be replanned around new network paths, new authentication and a different latency profile, which is work we usually pick up alongside cloud migration services in India. And where you want the same skills inside your own team rather than as a scoped engagement, hiring dedicated Java developers in India or .NET developers in India gives you engineers who work in the languages most ERP integration layers are already written in.