What do ai data integration best practices actually look like when the AI is not a chatbot but a piece of software that reads a real document and writes to a real record? They look like a chain of small, boring decisions about which system holds the truth, which document gets read, and, most importantly, who signs off before anything hits your ERP. If you get those decisions right, the integration is durable. If you get them wrong, you have built a fast way to corrupt your data.
Key takeaways
- Treat AI integration as an approval problem first and a pipeline problem second: every write to a live record should pass through a person on your team.
- Keep your ERP as the single source of truth. The AI reads from it and proposes writes to it, never replaces it.
- Scope the first build around one document type and one record type, not a company-wide rollout.
- The Kelsan rebate-and-margin system, built inside Epicor P21, has recovered over $100,000 in margin by reading supplier documents and surfacing entries for a human to approve.
- Every Throughline engagement starts with a fixed-fee AI Capability Audit at $7,500; the initial call is free.
What "AI data integration" actually means
Two verbs: read and write. An AI data integration reads something (a PDF, an email, a spreadsheet, a row in a database) and writes something back to a system you already run (an ERP, a CRM, a warehouse system). The AI part is usually the reading, because the documents are unstructured and messy. The integration part is the writing, because that is where the record actually changes.
A normal ERP integration moves structured data between two systems on a defined schema. An AI integration adds a step in front of that: turning messy input into structured output the ERP can accept. That extra step is where the risk lives, and it is why the practices below are about control, not throughput.
If you want the longer version of what we mean by wiring AI into the software you already run, we describe it as generative AI integration: the AI reads real documents and proposes writes to real records.
The five-step frame: read, match, propose, approve, write
Most vendor blogs in this space draw pipeline diagrams. We draw a shorter one.
- Read. The system ingests the document you already receive. Supplier rebate PDFs. Invoices. Order acknowledgments. Whatever is currently getting re-keyed by a person.
- Match. It finds the corresponding records in the system of truth. In distribution, that is usually your ERP: the invoice line, the PO, the vendor account.
- Propose. It drafts the entry it wants to make. Not "here is a summary." A specific write, on a specific record, with a specific number.
- Approve. A person on your team reviews the proposal and either approves, edits, or rejects it. This is the step vendor blogs skip. It is the one that matters.
- Write. Only after approval does the entry post to the ERP. The audit trail shows who approved, when, and what changed.
That is the whole shape. Everything else is plumbing.
Best practices that hold up in production
Keep the ERP as the source of truth
Your ERP is not a nice-to-have to sync with. It is the ledger. The AI system reads from it and proposes writes back to it. Nothing important lives in a separate AI database that then has to be reconciled. If you build a shadow copy of your data for the AI to work against, you now have two versions of the truth and a race condition. Don't.
If you run Epicor P21 or a similar mid-market ERP, this is the pattern for ERP automation that we default to: the ERP stays authoritative, the AI is a proposing layer on top.
Put the human in the loop before the write, not after
There is a lazy version of "human in the loop" where the AI posts entries and a person reviews them the next day. That is not human in the loop. That is human-cleaning-up-a-mess. Approval belongs before the write. It is slower to design and faster to trust.
Start with one document, one record, one workflow
Scope discipline is what separates a build that ships in a reasonable window from an IT program that never ends. Pick a document type your team already receives on a predictable cadence. Pick the single record in the ERP that would change if a person handled it manually. Build for that one path. Ship it. Expand later.
This is also what makes back office automation tractable: not automating "the back office," but automating one specific chore inside it.
Expose only the data the system needs
The AI does not need access to your entire ERP schema. It needs read access to the tables involved in matching, and write access (via approved proposals) to the specific fields that will change. Anything more is a security surface you did not have to create.
Make the audit trail native, not bolted on
Every proposal, every approval, every rejection, every write should be logged with a user, a timestamp, and the before/after state of the record. When your controller asks in month six why a rebate credit was applied to a specific invoice, the answer should be one query away.
What we built at Kelsan
Kelsan is a multi-state distributor running Epicor P21, and it sits inside our own group. We built a rebate-and-margin recovery system that reads supplier rebate documents, matches them against invoices already sitting in P21, and surfaces the proposed entries for a person on the Kelsan team to approve before anything posts. To date, the system has recovered over $100,000 in margin that would otherwise have leaked out through un-claimed or mis-applied rebates.
Nothing about that system is architecturally exotic. It reads the documents Kelsan was already receiving. It writes to the ERP Kelsan was already running. The interesting work was in the approval interface: making it fast enough that a person would actually use it, and clear enough that they trusted what they were approving. If you want the fuller version, it lives here: the rebate-and-margin tool we built inside Kelsan.
That is the pattern we would rebuild for any distributor in a similar spot, and the reason we publish specifics about AI for distributors rather than generic case studies.
How these projects fail
Two ways, mostly. The first is scope creep before the first ship: the team tries to solve rebates, invoicing, order entry, and forecasting in the same project, and none of them ship. The second is skipping the approval step to look faster on a demo, then discovering in production that the AI wrote a bad number to a live record and nobody caught it for three weeks. Both failures are avoidable. Both are common.
The less common failure is picking the wrong document. If the input document does not actually determine the write, the AI is doing an interesting reading exercise that changes nothing in the business. Pick a document that, today, causes a person to change a record. That is the one worth automating.
Ready to talk about a build?
If you are scoping a first AI integration into your ERP and want a straight conversation about whether it is worth building, we can help. Book a call with Throughline, or start with a fixed-fee AI Capability Audit ($7,500). The call is free. Call 865-417-3554.
About the author
Throughline is a small team of builders inside Keller Group. We build AI systems into our own operating companies first, then into yours.