Acumatica integrations matter when your finance and operations data lives in the ERP but your sales conversations, bookings and follow-ups happen somewhere else, and nobody trusts either side to be up to date. Connected properly, a won deal on the levelpartner.ai platform becomes a customer record in your ERP without anyone retyping it, and an overdue invoice in the ERP can start a polite reminder sequence on the platform. This article answers one question: which data should flow in which direction, and how to wire it up with the platform's workflow webhooks.
Decide the direction before the mechanism
Most integration projects stall because they start with the connector and not the data. Before anything is built, agree which system owns each piece of information. A sensible split for a services firm is this. The platform owns leads, enquiries, conversations, appointments and pipeline stages. The ERP owns customers once they are billed, invoices, payments received, and anything your accountants report on.
Data then flows in two narrow streams. From the platform to the ERP: a new customer when an opportunity is won. From the ERP to the platform: status changes the sales or account team needs to act on, such as an invoice going overdue or a contract renewal date approaching.
Before you start
- Agreement from your finance lead on which fields the ERP will accept from outside.
- Someone with administrator access to the ERP who can set up an outbound notification or an API user.
- A clear unique identifier shared by both systems, usually the customer email or an account number.
- Custom fields on the platform for anything the ERP sends back, such as account number or invoice status.
- A test customer you can create and delete in both systems without affecting real accounts.
How to set it up
- Write a one-page field map: each field, its owner system and the direction it travels.
- Open Automation and create the ERP hand-off workflow, or open an existing one.
- Give it a trigger, such as the pipeline stage changing to won.
- Click the plus icon where the ERP post belongs, so the Actions panel opens.
- Search the panel for "webhook" and select Webhook.
- Enter an Action Name such as "Post won client to ERP".
- Leave the Method on POST and paste the ERP endpoint into the URL field.
- Under CUSTOM DATA, click "+ Add item" for each ERP field on your map.
- Give each item a Key without spaces and a Value from the contact or deal.
- Click "Save Action", then "Test Workflow" and run the test on your test customer.
- In the Execution Logs tab, confirm the Webhook step shows Executed, then switch the Publish toggle on.
- For the return stream, create a second workflow and select Inbound Webhook as its trigger.
- Copy the webhook URL it generates and give it to your ERP administrator.
- Ask them to send a test POST request with JSON from the ERP to that URL.
- Map the incoming ERP fields to your custom fields, then click "Save Trigger".
Where your ERP cannot call a webhook directly, a middleware connector or a small piece of custom code can sit between the two. That is a scoped custom build rather than a settings change, and it is worth pricing before you commit.
What to sync and what to leave alone
Sync less than you think. The temptation is to mirror everything so that both systems show the full picture. That doubles the maintenance and creates conflicts whenever someone edits a record on the wrong side. Your sales team needs to know that a client is overdue, not every line of every invoice. Your finance team needs the billing contact and the agreed scope, not the full conversation history.
Say the consultancy closes around 25 engagements a month and a coordinator retypes each won deal into the ERP, at about 15 minutes a deal. That is roughly six hours a month, with an error in perhaps one record in ten. If a won-stage webhook created the customer record instead, the coordinator's job would shrink to checking a daily list in about ten minutes. Overdue invoice flags flowing back would let account managers call clients before finance has to chase. These numbers are assumptions, not measurements.
What it replaces and the weekly time
An integration like this replaces double entry, the weekly spreadsheet that reconciles sales and finance, and the awkward moment when an account manager pitches an upsell to a client who has not paid. Once live, allow around thirty minutes a week to review failed posts and mismatched records. The business process software guide explains how this fits alongside the rest of your stack.
The mistake most people make
They let both systems create customers. Sales adds a client on the platform, finance adds the same client in the ERP with a slightly different name, and the integration creates a third. Pick one system to create customer records, and have the other only update records that already exist, matched on the shared identifier.
Matching on company name. Names change, get abbreviated and get misspelled. Match on an email address or an account number that both systems store exactly.
When not to integrate
If your firm closes a handful of deals a month, retyping them may be quicker and safer than building and maintaining an integration. Revisit when volume grows or errors start costing money. Do not integrate before both systems are clean; connecting two messy databases spreads the mess faster. The article on process improvement covers tidying a process before you automate it.
Troubleshooting
The ERP rejects the webhook. The payload is missing a required field or uses the wrong format. Ask your administrator for the exact field list and match each Key under CUSTOM DATA.
Duplicate customers appear in the ERP. The workflow fires every time the opportunity is edited while in the won stage. Restrict the trigger to the moment the stage changes, and allow one pass per contact.
Incoming updates land on the wrong contact. The identifier is not unique on the platform. Search for duplicate contacts and merge them, then retest.
Updates stop without any error. An API credential on the ERP side expired. Set a calendar reminder for credential renewal dates.
Frequently asked questions
Do I need a developer for this?
For the platform side, no: webhook steps and triggers are configured in workflows. For the ERP side, you need whoever administers it to set up the endpoint or notification. Complex mapping may need a scoped custom build.
Should invoicing move from the ERP to the platform?
Usually not, if your accountants already rely on the ERP. The platform's payments and invoicing suit simpler billing. Keep financial records where they are reported.
How do we keep the integration documented?
Store the field map and the two workflow names in your process register. The operations and process management article suggests a format.
Can the platform read live ERP data on demand?
Workflows react to events rather than querying another system on demand. Send the values you need onto the contact record when they change.