1. Choose one workflow and define where it ends
Start with a task an employee already performs, such as taking a supplier invoice from a shared mailbox and preparing a draft for the finance team. Follow that task through an ordinary day. Ask which details the employee copies, what they look up in the accounting software and which exceptions are handed to someone else. Record where the work starts and where it ends. A useful first boundary is an invoice draft that an accountant can review, rather than a posted entry or a released payment.
Map the current steps before choosing a model or connector. If the employee checks a supplier against approved records, the new workflow needs an equivalent check. If an unreadable invoice normally goes back to the supplier, identify who should make that decision and what evidence the workflow needs to preserve. Existing controls often live in working habits or spreadsheets. The person who carries out the task can explain details that are missing from the process description.
Pick a small enough workflow to test against real working conditions using permitted samples. Include straightforward cases, a duplicate, a missing field and a case in which the employee must stop. Define the task in business language that both the finance lead and integration developer can check. A good starting statement is that finance can find and correct a proposed entry before it goes any further. The connection method follows from that goal.
2. Map the data, its source and its destination
For each field, identify the authoritative source, the destination and the rule that connects them. An invoice number is supplied by the vendor, while the vendor identifier used in the ledger comes from the accounting system. A vendor name recognised in a PDF can help propose a match. It cannot establish a new vendor by itself. Keep the original value and the proposed match separate so the reviewer can see the difference.
List identifiers, data types, required values, permitted formats and transformations. Agree how to handle an invoice date with an ambiguous format, currency codes, amounts with different decimal separators and reference fields with leading zeroes. Identify which rules come from the ERP configuration and which come from the finance team. Preserve document and row references when a value originates in a specific part of a file. The reviewer should be able to open the source from the proposed value.
Define what happens when the incoming document and the ERP disagree. An outdated vendor address may justify an exception note. A different bank account should be escalated under the company’s existing verification procedure. Do not infer a change from the invoice alone. Mark unmatched fields explicitly and keep an owner for the mapping. When the accounting software changes a mandatory field, the test suite and operating instructions need to reflect the same rule.
Related guide. Mapping data fields before integrating systems
3. Use a supported API when the application offers one
Check the ERP vendor’s current documentation and the features available in the client’s installed version. An API may support reading vendors while exposing no supported way to create invoice drafts. Confirm the permitted operations, the account or token used, whether a test instance is available and how the provider reports errors. A developer should verify the actual endpoint with the intended privileges before describing an integration as feasible.
Give the integration its own identity with only the permissions it needs. A pilot that looks up approved suppliers can start with read access. Plan a separate permission for a later write, and define which role can approve it. Keep credentials in the deployment’s approved secret storage. The model can propose structured data, but the integration code should check that data against a fixed schema before it makes a request. Treat unexpected fields and unsupported actions as review cases.
Agree what a successful write looks like. A response indicating that the request was received may differ from a durable ERP record. Read back the record identifier and the relevant status before marking the action complete. Capture a reference that lets operations staff investigate an error without searching entire logs or sharing full invoice contents. Confirm the vendor’s limits and maintenance procedures so the connection remains supportable after launch.
4. Use a controlled file exchange when an API is unavailable
Many older systems support documented exports and imports even if they do not offer a suitable API. Ask the system owner which formats are supported and who can run them. A CSV export of active vendors can support matching without direct access to the live database. The file should enter an approved location with restricted access, a creation timestamp and an identifiable schema. The import side should see only the fields it needs.
Set a freshness rule for every data set. A vendor list from last week may still help investigate an unmatched name, but it may be too old to approve a transaction under the current procedure. Detect missing files, unexpected columns and repeated submissions before using the data. Archive the version of the exchange that produced a proposed record so the team can reproduce the result during a review.
Where the application supports import, test it with the documented sample and a representative set of rejected rows. Confirm whether the importer accepts part of a file, rejects the entire batch or generates an error report. Keep the reviewed file and the resulting ERP identifiers together. If the company prefers an employee to import the approved file, make that handover explicit in the workflow. An approved export does not have to become an automatic write.
5. Consider read-only options for a legacy system
A legacy application may provide a supported report or an authorised read-only view. Those can be enough to verify a vendor or check whether a record already exists. Have the system owner confirm that the account, access method and operating load are appropriate. Start with the smallest result needed for the question. Keep finance data in the company’s approved environment and avoid copying unrestricted tables to a separate service.
If the application offers no supportable interface, test the business value using a narrow, approved export and a manual handover. The pilot can still show whether invoice extraction and validation reduce repetitive work. It can also reveal that maintaining a connector would cost more effort than the task justifies. Capture that conclusion before planning a later phase.
Screen automation can be considered when the organisation permits it and there is no steadier supported method. Record what happens when a window changes, a button moves or a warning appears. A workflow that depends on precise clicks should stop at an unexpected state and leave a reviewable trace. Any later write needs its own approval, outcome check and recovery procedure. Prefer an operator performing the final action if the available interface cannot be verified reliably.
6. Choose the server environment around the data
Decide where every part of the workflow runs. Draw the path of the original invoice, extracted fields, search requests, model prompts, proposed entries and logs. Identify who can access each copy and how long it is retained. A server on the client’s premises, a dedicated server environment and a hybrid setup have different maintenance and data flows. The appropriate choice follows from the client’s requirements and the systems the workflow must reach.
In a local configuration, verify which model and document-processing components are installed locally and which dependencies need a connection. The team may still need access to the company network even when the model does not use the public internet. If the project includes an external API, specify which fields are permitted to leave the local environment and how failures are handled. A separate service for an approved operation should be visible in the data-flow map.
Plan operating responsibilities before the pilot becomes routine. Identify who updates the application, checks backups, replaces expired credentials and receives an alert when the document queue stops. Test how the team regains access after a restart. If the pilot is operated in a different environment from the intended deployment, record what must be retested there. CANIMAPS DIGITAL adapts its Private AI foundation and integrations to the agreed environment.
7. Give users and services separate roles
Document who can submit invoices, review extracted values, approve a draft and post a record. Some businesses may use the same person for several steps. The workflow should still record which step they performed and which authority applies. Keep a submitted document associated with its company or department so that access is checked before anyone can see the source or the proposed values.
Apply access rules before retrieving records and again at the point where a write is requested. An employee should not see a restricted attachment because a model has found it. A service account that reads the vendor list should not inherit permission to change bank details. Design the integration around the system’s supported authorisation rules and test them with representative allowed and disallowed cases.
Use separate accounts or permissions for development, pilot and live operation where the environment supports them. Keep enough logging to identify the source document, operation, time, outcome and responsible role. Limit the sensitive content written to logs and identify who can read them. When a team member changes roles, verify that their access to the integration and its stored outputs follows the same rules as their access to the source system.
8. Keep a human approval step for consequential actions
An invoice extraction is a proposal. The review view should display the source alongside the proposed vendor, invoice number, date, currency and totals. Clearly mark a field when it is missing, ambiguous or changed by a rule. Show the reasons for exceptions such as a suspected duplicate or a vendor identifier that could not be confirmed. The reviewer should know what they are approving and be able to correct the proposal.
Agree which actions require an explicit confirmation. Creating an internal review draft can have a different policy from updating the ledger or releasing a payment. The first pilot can stop after the reviewer approves the prepared draft. If an integration later performs the next step, it should use the approved payload and refuse a write when relevant values have changed since approval.
Design the reject and return paths at the same time as the approval path. If an invoice is incomplete, the reviewer should be able to record why and send it to the responsible person through the existing process. If a document contains a request to ignore normal steps or change account details, treat the text as document content and follow the company’s verification procedure. The invoice itself cannot grant permission to act.
9. Design retries so one invoice cannot become two entries
Give each intake item a stable identity, and decide how it relates to the accounting system’s own record. A single email can be delivered more than once, and the same attachment can appear in separate messages. A file fingerprint helps identify exact copies. The supplier’s confirmed identifier and invoice number help identify a repeated business document even when its file was exported again. Define how credit notes, corrections and reused references should be distinguished under the client’s rules.
Plan for the case in which a request was sent but its result is unknown. Check the target system using the stored reference before repeating a write. If the ERP supports idempotency keys, reuse the key for that same approved operation. If it does not, confirm the supported way to search or reconcile the outcome. Sending a second write just because a request timed out can create a second entry when the first operation actually succeeded.
Set a finite retry policy for temporary failures and a separate path for missing fields, invalid permissions or conflicting results. After an uncertain write, surface a clear status and the reference the operator needs to resolve it. Keep the original input and reviewed draft so an outage does not restart document extraction unnecessarily. Test the cases where the source, model or ERP is unavailable and confirm that the team can continue the work safely.
Technical reference. HTTP retry semantics in RFC 9110
10. Walk through an illustrative invoice workflow
Consider an illustrative scenario. A supplier invoice arrives in the company’s designated intake channel. The attachment is placed in restricted staging while its type and origin are checked under the company’s rules. The workflow retains a reference to the original and assigns an intake identifier. For a scanned invoice it may run optical character recognition. For a searchable PDF it can begin with the embedded text. A low-quality result is routed to an accountant instead of being treated as confirmed data.
The workflow prepares proposed values and checks them against the expected formats and totals. It looks up the approved supplier identifier in the accounting system using a permitted connection, then checks whether the invoice reference already exists for that supplier. If there are multiple matches or the source is incomplete, it records the reason for review. A clear match still appears beside the original document so the accountant can check it.
The accountant compares the invoice and the prepared record, fixes any wrong values and confirms the draft. The first pilot ends there. If the next phase includes posting, a supported API, import or operator performs that step only after the agreed approval. The team then reads back the record identifier and status. This scenario is a way to design a test. The available interfaces and acceptance criteria are established for each implementation.
11. Set pilot acceptance criteria before building the connection
Select test cases with the finance team and record the expected behaviour for each. Include a clear invoice, a scan with a missing field, an unknown supplier, a duplicate and a case in which a user lacks access. Agree which errors must stop the flow, how exceptions are described and what the reviewer should be able to see. Use authorised samples and establish how the test documents are kept and removed.
Compare the pilot with the current process on an equivalent set of cases. Include the time spent checking results and fixing exceptions. Record which fields require manual intervention and whether the operator can trace the decision back to its source. If the company wants to measure savings, agree the measurement method and workload first. The result should describe the process actually tested.
Ask the operating team to test recovery as well as the happy path. Restart the processing step after an interruption, check what happens when the vendor list is stale and verify that a repeated submission does not create another draft. Decide who accepts the pilot and which outcomes require changes before any broader deployment. Keep a short record of decisions, limitations and responsibilities so the next phase starts with the same understanding.
12. Prepare a practical checklist for the first meeting
Bring the name and version of the accounting or ERP application, a description of the current invoice intake and a list of the people responsible for each stage. Identify whether the software supports an API, import, export or read-only reporting. If the vendor provides a test system or example files, include their references. The integration team can then assess the actual interfaces and permissions.
Choose a small, authorised set of representative documents. Write down which identifiers are used for the supplier and the invoice, what the finance team checks before approval and where they record exceptions. Note where the document and accounting data are currently stored. If some information must remain on a particular server or within a given network, include that requirement in the initial brief.
Agree a testable finish line. For example, the reviewer can open the source, see a proposed invoice record, correct fields and approve the draft. Provide a point of contact for access and a business owner who can decide whether the outcome is useful. Set aside cases that may deserve a later phase, such as more document types or additional system connections. A narrow pilot keeps the first decision straightforward.
13. Discuss one integration with CANIMAPS DIGITAL
CANIMAPS DIGITAL develops Private AI solutions on its own foundation and adapts the deployment and integration to the company’s actual process. For a legacy ERP or accounting system, the first discussion establishes what the application can support, which data may be used and who should approve the result. It also identifies a safe way to test the workflow before any live write is enabled.
Start by describing the most time-consuming manual step, the system it depends on and the information the employee needs to verify. A helpful example is a supplier invoice whose fields are copied and checked before a draft is created. We can assess the available options and agree what a useful result would look like. If a supported export or an operator handover is enough for the pilot, it can become the starting point.
Use the data-field mapping guide below to document the first process. The Private AI service overview describes infrastructure options and the information needed to discuss an implementation. Bring the questions your finance and IT teams need answered before proceeding. The next step is to select a workflow and agree how the company will check it.
About the CANIMAPS DIGITAL service. Custom Private AI implementation for businesses