Short answer. The accounting, invoicing, ERP or till that already exist are not replaced; they are connected, and the work is not in the cable but in the integration layer: a queue where every message carries an idempotency key, a mapping table where the app’s identifier is stored next to the target software’s number, a transformation to a common data contract, a log, and a reconciliation every evening that lists the gaps instead of hiding them. Connectors speak each program’s language: the API when there is one, file exports and imports when the program has run on Windows for ten years, the database read-only, the screen as a last resort. Sixteen weeks, two of inventory and two during which the first flow runs in parallel with manual entry.
This guide is for the distributor whose orders are re-entered in invoicing, the chain of shops whose tills send an evening file somebody retypes, the clinic whose diary and invoicing do not talk, the real-estate agency whose receipts reach the accountant as photos, and the founder settled in France who reads “ERP integration” in a quote without knowing what it hides. It does not compare software, and the guide on migrating old business software covers the case where you end up replacing; here, you keep and connect.
What the figures say
Integration has become software’s normal job. Postman’s 2025 State of the API report, seventh edition, surveyed more than 5,700 developers and professionals between July and August 2025; according to its 8 October 2025 release, 65 % of organisations generate revenue from their APIs and nearly one developer in four already designs APIs for AI agents; the 2024 edition said nearly three quarters of professionals worked “API first”. These are worldwide figures relayed by the trade press, to be read as a direction: software that exposes nothing is becoming the exception, and yet it is what you find in most Algerian companies, on Windows, installed in 2016.
Modern vendors document their front door, and its conditions. Odoo, present in many SMEs, exposes its external API over XML-RPC, with an authentication call returning a user id, API keys since version 14 replacing the password in scripts, and, according to the version 18 documentation, access to data through the external API reserved to “Custom” plans on Odoo Online; a company planning to integrate its vendor-hosted Odoo must check that before signing a quote. On the return side, the Standard Webhooks initiative, steered by a committee with engineers from Zapier, Twilio, Svix and Kong, recalls that “every webhook implementation needs to protect themselves and their users from SSRF, spoofing, and replay attacks”, and provides tools to sign and verify; AI providers such as OpenAI, Anthropic and Google have adopted it. What this imposes on the company: a webhook received without signature verification is an open door, and a webhook received twice must produce one effect.
The rest is Algerian and appears in no report: the Windows invoicing software whose vendor no longer answers, the external accountant who wants a file and not an API, the till that exports a CSV at closing, the Excel workbook three people edit. We have no statistics on these cases; we meet them in almost every project, and this guide is written for them as much as for Odoo.
The life of an order across the software, in six moments
The integration is not described by its connectors but by what happens to an order confirmed in the app, until the accountant and the manager see the same figure.
The event is born in the app: a confirmed order, time-stamped, with an identifier created once and for all, a long random identifier, not a number the invoicing software will assign later. The data contract is the object every program will receive: customer, lines, quantities, prices, taxes, references, in a single format written in the first week; each connector translates it into its program’s language, and the mapping table keeps, for every customer, product and order, the app’s identifier and each program’s. The send goes through a persistent queue: the message carries an idempotency key, a status and an attempt count, and leaves through the API if there is one, through a file dropped in a watched folder otherwise; never twice, even if the connection drops after sending, by the same mechanism the guide on the offline app describes for the phone.
The acknowledgement and the return identifier are the moment that makes the integration last: invoicing returns its number, 2027-0142, and it is stored next to the order identifier; when no answer comes, the “pending” status is visible, and an imported file is checked by re-reading the result in the program. Without that identifier alongside, nobody can say six months later which invoice matches which order, and that is exactly what happens when the integration was done “with a cable”. Events coming back make the reverse journey: the payment entered in accounting or the stock corrected in the ERP come back to the app, by signed webhook if the vendor offers one, by periodic read otherwise, and the app updates the retailer’s balance or the product’s availability. The evening reconciliation compares both sides, order by order: what is missing on one side, what differs in amount, what is duplicated; every gap is listed with its probable cause, replayed in one click when it is a technical failure, arbitrated by the accountant when it is a real disagreement. It is the same reconciliation the till guide describes between the payment terminal and the statement.
The integration, in five layers
Behind the six moments, five layers, and the middle one is the only one really built.
The existing software stays in place: accounting keeps being kept by the accountant in their program, invoicing keeps numbering, the ERP keeps managing stock, the till keeps collecting; each keeps what it does well, and that is what makes the project acceptable to the people who use them. Connectors speak each program’s language, and nothing else knows it: an XML-RPC connector for Odoo, a file connector for the Windows invoicing software, a database reader for the ERP, a webhook connector for the SaaS vendor; when a program changes, one connector changes, and the rest does not move.
The integration layer is the real deliverable: the persistent queue with idempotency keys, the transformation to the data contract, the identifier mapping table, the log of every message and response, and the rules of what is authoritative, accounting for the entry, the app for the order, the ERP for stock. The app emits and receives events and does not know how the books are kept; that is what lets you change accountant, program or vendor without touching the app. Supervision is a screen the accountant and the manager read in the evening: gaps per flow, rejections with their reason, queues stuck for more than an hour, and a “replay” button; an integration without that screen is one whose holes you discover on the 30th. The ordering portal and the WhatsApp agent, described in the B2B portal guide and the WhatsApp agent guide, are event emitters like any other: the integration layer does not know whether the order came from a pre-seller, a portal or a voice note.
«Wiring the app into the accounting API is laying a cable; the integration is the queue, the key, the mapping and the reconciliation.»
A worked example
An example on volume assumptions, with results that are not assumptions: a distributor, four programs, one month.
Four programs: the Windows invoicing software installed in 2016 that exports and imports files, the bookkeeping kept by an external firm that wants one file of entries a month, the depot till that exports its sales at closing, and the bank that provides a statement to download; none of the four has an API, and the integration works anyway, by files and by reads. 1,200 invoices a month are created in the invoicing software from the app’s orders: a file dropped every hour in the folder the program watches, re-read after import to retrieve the invoice number and store it next to the order; an order whose number has not come back in thirty minutes shows as “pending” on the supervision screen.
Zero re-entry is the result that depends on no assumption: the invoice is typed once, by nobody, and the entries leave every evening to the accountant in their program’s format; the payments they enter come back in the morning by reading the file they export, and the retailer’s balance updates in the pre-seller’s app described in the pre-sale guide. Three hours to fifteen minutes of month-end reconciliation is our assumption: gaps are listed every evening, about ten a day at first, two or three after a month, and on the 30th there is nothing left to hunt. The assumptions to check at home: how many programs, how many invoices, who re-enters what today and how long reconciliation takes; a day of observation at the depot and an hour with the accountant answer all four.
Six ways of reaching the existing software
Every program can be connected, but not the same way, and the project’s first week is spent finding which of the six situations applies to each.
The documented API is the comfortable case: Odoo over XML-RPC, a recent program over REST, a SaaS vendor with keys and quotas. The connector respects pagination and limits, uses a key in the company’s name, and is tested in a sandbox before touching production; it also checks that API access is included in the subscription, which is not always the case, as Odoo’s documentation recalls for its online offer. File exports and imports are the most frequent Algerian case: most Windows invoicing and accounting programs can import and export CSV or Excel; the app generates the file in the exact expected format, drops it in a watched folder, and re-reads the result to get the acknowledgement. It is less elegant than an API and just as reliable when the re-read exists. The accessible database is read, read-only, to retrieve invoices and payments; you never write directly into the database of a program you do not control, you go through its official import.
The screen alone is the last resort: no API, no useful export, an unreachable vendor; screen automation, a robot typing into the program like a human on a dedicated machine with proof captures, works, and it breaks at every program update; it always comes with an exit date, often that of the migration described in the guide on old business software. The foreign SaaS vendor offers webhooks that must be verified by signature, protected from replay and received on a server that answers fast; keys are in the company’s name, and paying for the service in foreign currency follows the guide on paying for cloud from Algeria. The shared Excel file is not software but a habit: either the app becomes the source and Excel an export anyone can still open, or the workbook is imported once and retired; keeping it alive next to the app creates a third truth.
«Accounting receives; it does not drive the operation.»
Six companies, what gets connected first
Six companies we often equip, and for each the first connected flow, which is always the one re-entered today.
The distributor first connects the app’s orders to invoicing and collections to accounting; ERP stock to the app and bank statements to reconciliation come next. The chain of shops connects each till’s sales to central stock and accounting every evening, then loyalty and receipts to the customer space and central prices to the tills. The clinic or practice connects diary procedures to invoicing and payments to accounting, then lab results to the file; the dental practice receiving the diaspora, described in the dedicated guide, has exactly this first flow.
The real-estate agency connects the app’s receipts to accounting and collected rents to the owner statement described in the guide on the flat managed from France, then the bank statement to rent reconciliation. A founder’s SaaS connects its subscriptions and invoices to its own accounting by monthly export, then gives each customer an export in that customer’s program format, which is often the feature that makes an SME sign. The importer with an ERP connects the ERP’s catalogue, prices and balances to the B2B portal and the portal’s orders to the ERP, then delivery statuses to the WhatsApp agent. In all six cases the first flow runs from the event to accounting, never the reverse: accounting receives, it does not drive the operation, and that rule avoids most truth conflicts.
Seen elsewhere: Odoo, Standard Webhooks, Postman, and what transposes
Three public texts say the essentials. Odoo’s external API documentation shows what a well-made front door looks like: an authentication call, per-user API keys since version 14, methods to search, read, create and write on models, and a commercial condition, access reserved to certain plans on the online offer, to be read before promising an integration. What transposes to any program: check access before pricing, one key per company and never the manager’s password in a script, and a sandbox to test. Standard Webhooks says the other half: a webhook is a request a third party sends to your server, and it must be signed, verified, time-stamped and protected from replay; AI providers have adopted it, and the same principle applies to the WhatsApp webhook or an online invoicing vendor’s.
Postman’s report says where the market is going: APIs everywhere, revenue depending on them, and a growing share of APIs designed to be called by AI agents rather than screens; the WhatsApp agent described in the dedicated guide is exactly that, an API caller. What does not transpose: the assumption that the API exists. In Algeria it does not exist for half the programs encountered, and the integration layer is precisely what makes files, read-only databases and even the screen as reliable as an API: the queue, the key, the mapping and the reconciliation do not depend on the connector.
The rules of an integration that lasts
Six rules, written in the first week and reread at every new flow. One truth per datum: the order belongs to the app, the entry to accounting, stock to the ERP, and every program receives the other data as copies; two programs claiming the same datum diverge within a month. One idempotency key per message and a persistent queue, so that a repeated send creates one invoice. A mapping table where every identifier has its twin in every program, without which nothing reconciles. A log of every message and response, readable by the accountant. Accounts, keys and access in the company’s name, never the vendor’s, as the guide on the app stuck with a vanished developer recalls. A sandbox and a parallel period: the first flow runs two weeks alongside manual entry, both are compared every evening, and entry stops only when the gaps are explained.
A seventh rule concerns the specification: “integration with accounting” is not a requirement, it is a sentence; the requirement reads “confirmed orders create an invoice in program X by file import within thirty minutes, the invoice number is stored next to the order, and the day’s gaps are listed at 8 pm”, and it is checked at acceptance, as the guide on the specification recommends. A quote that prices “integration” without saying by what means or for which flows has priced something else.
The 2027 calendar
The calendar is that of a sixteen-week integration, whose first two weeks produce no code and two others run the first flow in parallel with manual entry.
Weeks 0 to 2 take the inventory: each program, its version, its access mode among the six, each flow re-entered today and by whom, and the data contract written with the accountant. Weeks 2 to 4 obtain access: API keys in the company’s name, export and import formats tested on real data, a sandbox when the vendor offers one, and the vendor contacted when something must be asked of them, which always takes longer than planned. Weeks 4 to 8 build the integration layer: queue, idempotency, mapping, log, gaps screen, and the first connector. Weeks 8 to 10 run the first flow in parallel: invoicing receives the app’s invoices and the usual manual ones, and both are compared every evening until the gaps are understood. Weeks 10 to 12 wire the returns, payments and stock, and automatic reconciliation. Weeks 12 to 14 stop manual entry flow by flow. Weeks 14 to 16 put supervision into the accountant’s routine and review: gaps per flow and per week, rejections, and the decision on the program that will one day be replaced. What a year of this layer then costs, connector updates included, follows the logic of the guide on keeping an app alive.
What makes an integration fail
The integrations we see fail almost always fail for one of these reasons.
- Wiring the app straight into the API. A cable, not an integration: at the first change of program or accountant, everything is redone.
- No mapping table. Six months later nobody knows which invoice is which order, and reconciliation becomes impossible.
- Two programs holding the same datum. Stock in the ERP and in the app, edited on both sides; they diverge within a month.
- Writing directly into a program’s database. It works until the update that changes a table; the official import survives.
- No daily reconciliation. The gap is found on the 30th, three weeks old, and nobody knows where it came from.
- Stopping manual entry on day one. Without the two parallel weeks, format errors are learned in the month’s accounts.
- Keys in the vendor’s name. Changing vendor means requesting every access again, and the software vendor does not always answer.
Frequently asked questions
The questions we receive from managers, accountants and founders settled in France.
- My invoicing software has no API. Can it still be integrated?
- Yes, in almost every case: most Windows programs import and export files, and a file dropped in a watched folder then re-read to check the result is worth an API when the queue, the key and the mapping exist behind it. The database is read read-only, and the screen is automated as a last resort, with an exit date.
- Should the accounting be replaced or kept?
- Kept, almost always: the books are kept by an accountant who knows their program, and the project consists in sending them correct entries in their format rather than imposing a tool. Replacement, if it ever happens, is another project, described in the guide on migrating old business software.
- How are duplicate invoices avoided?
- With an idempotency key on every queued message and the return identifier stored next to the order: a repeated send is recognised and creates no second invoice, and an already-numbered invoice does not leave again. The evening reconciliation catches whatever slipped through.
- What if the software vendor does not answer?
- You do not wait: you connect by files or by database read, which ask nothing of the vendor, and you note the question for the future migration. Screen automation remains possible, on a dedicated machine, with a written exit date.
- Who looks at the gaps every evening?
- The accountant or the person who used to re-enter: the supervision screen lists gaps per flow with their probable cause and a button to replay technical failures; real disagreements, an unplanned discount, a different price, are arbitrated by them. Ten gaps a day at first, two or three after a month.
- How long before re-entry stops?
- Ten weeks for the first flow, two of inventory, two of access, four of build and two in parallel with manual entry; then about one flow every two weeks. A four-program project fits in sixteen weeks when access arrives on time, and the vendor who does not answer is what most often stretches the calendar.