Integrating a new platform with finance, identity and messaging
How should you approach platform integration with finance, identity and messaging systems?
Integrations with finance, identity and messaging are usually the long pole; scope them first and test against real message flows. Platform integration slips when left to the last month, so inventory every interface in week one, build finance and SSO links early, and rehearse end-to-end flows with real records.
Platform integration is the part of an implementation most likely to slip the go-live date, because a new CRM, ERP or HRMS is only useful once it exchanges data with the accounting system, the identity provider and the channels customers and staff actually use. Scope those three integrations in the first week, build them before configuration is finished, and test them against real message flows rather than sample payloads. Everything else in the project can be adjusted; a finance link that posts the wrong journal or an SSO that locks out a department cannot be talked around. This is how we run the integration stream inside an enterprise platform implementation.
Three systems recur in almost every project: finance (invoices, payments, journals, GST), identity (who can log in and what they can see) and messaging (email, WhatsApp, SMS, telephony). They are the long pole because each is owned by a different team, each has its own change process, and each is where the business will first notice a mistake.
What a system integration project has to cover
An integration is a contract between two systems: which events flow, in which direction, with what fields, how often, what happens on failure, and who is the source of truth for each field. Most integration projects skip the last two questions and discover them in production. CRM ERP integration is the classic case: the CRM thinks it owns the customer, the ERP thinks it owns the customer, and after six months there are two customers with different credit limits. Decide ownership per field in writing before a line of code.
The three integrations compared
| Integration | Typical flows | Hard part | Test that matters |
|---|---|---|---|
| Finance (Tally, SAP, Zoho Books, NetSuite, custom ledgers) | Customer and vendor master, invoices, payments, credit notes, journals, GST e-invoicing | Master data ownership, posting rules, reconciliation of totals | Month-end closes with every posted document reconciled |
| Identity (Entra ID, Google Workspace, Okta, custom) | SSO login, user provisioning, role mapping, joiner-mover-leaver | Role mapping to the platform's permissions; leaver de-provisioning | A new joiner can log in on day one; a leaver cannot on day one |
| Messaging (email, WhatsApp Business, SMS, telephony) | Outbound notifications, inbound conversations, templates, consent, delivery status | Template approval, consent records, threading inbound replies to the right record | A real customer conversation lands on the right record with status updates |
Finance: agree ownership and posting rules first
Start with a field-level ownership map. Usually the CRM owns lead-to-customer, the finance system owns credit terms and balances, and the platform being implemented owns whatever operational documents it generates. Then agree posting rules: which platform events create which finance documents, with which ledger codes and tax treatment. In India this includes GST e-invoicing, where a sales invoice above the threshold must be registered and carry an IRN; GST and e-invoicing integration covers the details. Build the finance link early enough to run a full month-end in a test environment, and reconcile totals with the finance controller before go-live. A finance integration tested with ten invoices will fail on the first credit note.
Identity: SSO is the easy half
SSO integration with SAML or OpenID Connect is usually a day's work against a mature identity provider. The hard half is provisioning: creating users with the right roles when they join, changing roles when they move, and removing access the day they leave. Map the platform's roles to identity groups, decide who owns group membership (HR through the HRMS, or IT by request), and automate the leaver flow first because it is the one auditors ask about. If the platform supports SCIM, use it; if not, a scheduled sync from the identity provider with an exceptions report is the fallback. SSO, RBAC and audit logs describes the model from the product side.
Messaging: test with real conversations
Messaging integration looks simple on the diagram and is where the most production surprises live. WhatsApp Business requires approved templates for outbound messages, a 24-hour customer-service window for free-form replies, and consent records that must be stored and honoured. Email needs sending-domain authentication, threading so replies attach to the right ticket or deal, and bounce handling. Telephony needs call records and recordings attached to the right contact. Test each with real flows: a customer replies to a notification three days later, a staff member forwards an email into the system, a call comes from a number attached to two contacts. Our voice agent integration guide covers the telephony patterns, and the same threading problems apply to every channel.
Patterns that keep integrations maintainable
Events over polling
Where the source system can emit events (webhooks, change data capture, message queues), use them. Polling works but creates lag and load, and it hides failures: a poll that returns nothing looks the same whether nothing changed or the credentials expired.
Idempotency and retries
Every message must be safe to deliver twice. Use the source document's identifier as the key, and design the receiving side to update rather than duplicate. Retries with backoff and a dead-letter queue turn transient failures into a morning's review rather than a midnight page.
An integration ledger
Keep a record of every message: what was sent, when, to which system, with what result. When finance asks why an invoice is missing, the answer should take one query. This ledger is also what makes the month-end reconciliation possible. For teams that want observability across integrations and AI components together, the same tracing discipline described in LLM observability applies.
Sequencing the integration stream
Week one is the inventory and the ownership map. Weeks two to four build the finance link against a test company and the SSO login, because both depend on other teams' calendars and the sooner a request lands with the finance controller or the identity administrator the sooner it is scheduled. Weeks four to seven add provisioning, messaging templates and inbound threading, then the integration ledger and monitoring. The last fortnight before go-live is reserved for the test month-end and the real-conversation scenarios, with no new integration work started. Teams that begin integration after configuration is finished compress all of this into the last month and discover the finance posting rules on the day the controller is on leave.
A worked example
A university modernising its ERP needed the student system to post fee invoices and receipts to the finance package, to give every student and staff member single sign-on from the institution's identity provider, and to send fee reminders and admission updates by email and WhatsApp. The finance link was built first, and the first test month-end exposed a mismatch in how partial payments were being posted; fixing it before go-live saved the finance team a reconciliation nightmare. Identity mapped roles to existing groups, with the registrar's office owning student status. Messaging templates were approved weeks ahead, and inbound replies threaded to the student record. The modernisation without a rewrite went live with integrations that had already survived a real month.
Team and timeline
An integration engineer per stream (finance, identity, messaging), often the same person for two of them on a mid-size project, with a solutions consultant owning the ownership map and a project manager coordinating the finance, IT and marketing teams on your side. Integrations run six to ten weeks in parallel with configuration and migration and are included in the enterprise platform implementation service from $28,000 (from ₹18,40,000). Standalone integration work runs under API development and integrations from $7,000 (₹4,40,000). Once live, integrations need watching: a Care Plan from $1,000 per month covers monitoring, credential rotations and vendor API changes, with options on the pricing page.
Before you start: a checklist
- Inventory every system the platform must exchange data with, and who owns each
- Write a field-level ownership map for customer, vendor, employee and product data
- Agree finance posting rules and tax treatment with the controller
- Map platform roles to identity groups and decide who owns membership
- Automate the leaver flow before the joiner flow
- Submit WhatsApp and email templates for approval early
- Plan a full test month-end and a set of real conversation scenarios
- Design retries, idempotency and an integration ledger from the start
Questions clients ask
- Should we use an iPaaS or build the integrations? An integration platform suits many simple, standard connectors; custom code suits a few complex ones with business rules. Most projects use both.
- What if our finance system has no API? File-based exchange with a reconciliation report is workable; plan for it and automate the file handling.
- Who fixes an integration when a vendor changes its API? Whoever holds the Care Plan; vendor changes are the most common maintenance ticket.
- Can AI help with integration? For mapping messy fields and classifying inbound messages, yes; for the contract between systems, no.
- How do we test without touching production finance? A test company in the finance system with a full month of representative documents.
Related reading
Data migration for platform implementations covers the stream that runs beside integration, and HRMS implementation: a 90-day plan shows payroll and identity integration in one project. For the messaging rules that catch teams out, Meta's WhatsApp Business Platform documentation is the primary source on templates and the customer-service window.
Scope finance, identity and messaging first, build them early, and test them with real flows, because they are the integrations the business will judge you by.
Frequently asked questions
Why are finance, identity and messaging integrations the long pole?
▾
Each is owned by a different team with its own change process, each has rules the platform must respect (posting, provisioning, template approval), and each is where the business first notices a mistake. Starting them late is the common cause of slipped go-lives.
What is the difference between SSO and provisioning?
▾
SSO lets a user log in with corporate credentials and is usually quick to set up. Provisioning creates, changes and removes accounts and roles as people join, move and leave, and is the harder, more important half for security.
How do you test a CRM ERP integration properly?
▾
Run a full test month-end with representative documents including credit notes and partial payments, reconcile totals with the finance controller, and keep an integration ledger so every posted document can be traced. Ten sample invoices are not a test.