Salesforce CRM Bi-Directional Sync

The problem this solves

Sales lives in the CRM. Finance lives in the ERP. Neither team is going to move, and neither should have to. What breaks is the seam between them.

A rep closes an opportunity in the CRM. Somebody re-keys it into SAP Business One as a Sales Order — usually a day later, usually with a different account name, sometimes against a Business Partner that already exists twice. Finance issues the A/R Invoice. The rep, who cannot see the ERP, calls the customer about a renewal while a sixty-day-overdue invoice sits unpaid. Meanwhile the CFO's pipeline number and the ERP's order book disagree, and every month-end starts with an argument about which system is right.

The usual fixes make it worse. A nightly one-way export means the CRM is always a day stale and nothing flows back. Giving reps ERP logins creates a licensing and permissions problem nobody wants. Manual re-keying scales linearly with headcount and introduces exactly the duplicate accounts that make reporting impossible.

The real requirement is narrower and harder: agree which system owns each field, sync continuously in the direction that ownership implies, and make conflicts visible instead of letting the last writer win silently.

What ECOSIRE builds

ECOSIRE builds a per-tenant integration between your Salesforce org and your SAP Business One company database. It is built to order against your object model, your custom fields and your document flow — there is nothing to download.

Account and Business Partner synchronisation

Salesforce Accounts and SAP Business One Business Partners are matched on a key you nominate — tax registration number, an external ID, or a composite rule — and linked permanently through an ID stored on both sides: a custom field in Salesforce and a UDF on the Business Partner. Field ownership is decided per field during scoping. Typically sales owns contact details and account hierarchy, while finance owns payment terms, credit limit, tax group and currency. Each field syncs only in its owning direction, so a rep editing a phone number never overwrites a credit limit and finance never resets a territory assignment.

Credit status flows back to the CRM as read-only information — credit limit, current balance and whether the account is on hold — so a rep sees the problem before promising delivery. Contacts sync to the Business Partner contact persons.

Quote to order

A Salesforce Quote or closed-won Opportunity creates a SAP Business One Sales Quotation or Sales Order through the Service Layer, with line items mapped from Salesforce Products to your ItemCodes through a mapping table held in a UDT. Pricing behaviour is agreed rather than assumed: either the CRM price is authoritative and carried through, or the ERP recalculates against a nominated Price List and any variance is written back to the CRM record for the rep to see. Discounts beyond a threshold can be routed into a SAP Business One approval procedure before the Sales Order is released, so commercial governance stays in the system that owns the money.

The resulting DocNum and DocEntry are written back to the Salesforce record immediately, giving the rep a real ERP reference without an ERP login.

Order, delivery and invoice status back to the CRM

This is the direction most integrations neglect. Order confirmation, Delivery documents with tracking, A/R Invoice number and date, invoice total, amount paid, outstanding balance, due date and days overdue are pushed back onto the linked Salesforce record on a schedule. Reps see fulfilment and payment status where they already work. Renewal conversations stop happening against unpaid accounts, and collections stops being purely a finance chase because the account owner can see the same balance.

Where your process requires it, Incoming Payments and Journal Entry references can be surfaced too, and Return documents or A/R Credit Memos update the CRM record rather than leaving a stale won opportunity behind.

Item and price visibility

Items, item groups and prices from nominated Price Lists are synchronised to Salesforce Products and Pricebook entries, optionally with on-hand availability by warehouse, so reps quote from what exists rather than from a stale product sheet.

Conflict handling and control

Every synchronised record carries a link and a last-sync stamp on both sides. Where both systems changed the same owned field between runs, the conflict is surfaced in a UDO-based control screen inside the SAP Business One client rather than silently resolved. That screen shows record type, direction, last attempt, the actual API error where one occurred, and a manual retry. Sync activity is logged for audit, and a reconciliation view lists linked records, unlinked records on either side, and suspected duplicates by the matching key.

Crystal Reports layouts for pipeline-to-order-book reconciliation can be included where reporting is in scope.

Who this is for

Organisations running Salesforce as the system of record for selling and SAP Business One as the system of record for finance and fulfilment, with enough deal volume that manual re-keying is a real cost and enough field overlap that ownership actually needs deciding. It fits B2B distributors, manufacturers with a field sales team, and services businesses whose reps need invoice status without an ERP licence.

It is a poor fit if your CRM is barely used, or if you have not yet decided which team owns customer master data — that decision is a prerequisite, not something an integration can resolve for you.

How delivery works

1. Scoping call. We work through the objects in scope, your custom fields, the matching key for account linkage, and the field-by-field ownership matrix. We agree the quote-to-order flow, pricing authority, approval thresholds, which statuses flow back, sync frequency, and how duplicates and conflicts should be handled. We confirm your Salesforce edition and API access, and your SAP Business One version, database platform and hosting.

2. Fixed quote. Written scope and fixed price before development starts. Additional objects, custom flows or reports appear as named line items.

3. Build. Development against the Salesforce REST API and the SAP Business One Service Layer, with DI API used where document behaviour requires it. UDFs, UDTs and UDOs are created by an install routine.

4. Install into test, then production. Installed against a Salesforce sandbox and your SAP Business One test company database, run with your real records including an initial matching pass over existing accounts. You sign off the linkage results, conflict handling and document creation before production cutover.

5. Support. A post-go-live support window covers defect fixes and platform API version changes on either side. Continued support beyond it is a separate agreement.

Typical lead time from signed quote to production install is one working week. The variable is almost always the ownership matrix and the state of existing account data — a clean matching key shortens the project, thousands of near-duplicate accounts lengthen it.