QuickBooks plus a spreadsheet for everything else
The books are in an accounting package, but quotes, purchase orders, stock counts and job costs live in spreadsheets someone updates by hand at the end of each week.

Odoo implementation · United States
Azinove is an Odoo partner and a senior engineering team. We help US companies replace a patchwork of accounting software, spreadsheets and single-purpose apps with one Odoo covering sales, purchasing, inventory, manufacturing, projects and invoicing. To be clear from the start: we have no US office. We work remotely from Strasbourg, France, and from our headquarters in Bahrain, with a process built for that distance: written scoping, configuration demos by video, user acceptance on a test database and every decision recorded.
Odoo partner · Remote delivery from Europe & the Gulf · In-house development
Why US companies call us
The trigger is rarely a feature. It is the hours spent moving the same numbers between tools that were never meant to work together.
The books are in an accounting package, but quotes, purchase orders, stock counts and job costs live in spreadsheets someone updates by hand at the end of each week.
Stock sits in more than one warehouse or location, the counts disagree with the books, and sales promises dates that purchasing cannot see.
Two or three companies share customers, products or staff, and every consolidated view is rebuilt manually from separate files.
An earlier Odoo rollout is out of date or over-customized, or a legacy ERP no longer follows how the company actually sells and ships.
How we frame the problem
Sales tax, entity structure, currencies and the data you bring over shape every screen that follows. We settle them on paper first.
Small ERP projects often start by clicking through settings. Sales tax gets handled late, the second entity is bolted on after go-live, and years of spreadsheet history are imported without anyone deciding what is worth keeping.
We write down the scope, the entity and currency structure, the sales tax approach and the migration plan, demo each part of the configuration by video, then have your team test it on a copy of the database with their own data.
One Odoo your sales, operations and finance teams all work in, configured around how the company really operates, and documented well enough that you are not dependent on us to understand it.
Capabilities
Configuration, migration, custom development and support stay with the same senior team, so nothing gets lost between a consultant and a subcontractor.
Sales, CRM, purchasing, inventory, manufacturing, projects and invoicing configured department by department, with roles and access rules.
Multi-state sales tax through Odoo’s settings or a tax connector chosen with you, several companies in one database, USD and other currencies, US date and number formats.
Customers, vendors, products, open balances and selected history moved from your current tools, an older Odoo or another ERP, reconciled before go-live.
Custom modules in Python only where the standard modules cannot express a real business rule, plus training and support after launch.
Possible deliverables
The proposal lists which of these are in scope; nothing is assumed.
Written scope: modules per department, what stays standard, what is customized
Entity, currency and chart-of-accounts structure, agreed with your accountant
Sales tax approach for the states where you have obligations, documented
Migration plan, mapped data and reconciled opening balances
Configured Odoo with roles, access rules and US-format documents
Recorded configuration demos, user guides and a written support arrangement
Example scopes
Illustrations of possible scopes, not packages and not past client projects.
A distributor or small manufacturer moves quoting, purchasing, stock and invoicing into one Odoo, keeping the books consistent from the first month.
A group of related LLCs gets shared products and contacts, separate books and a consolidated view, with intercompany flows decided up front.
An outdated or heavily customized installation is reviewed, customizations are kept, replaced by standard features or dropped, and the data is moved.
Guardrails
Working with a remote partner only holds up if the limits are written down.
We have no US office or US entity and do not offer on-site work in the United States; the whole engagement runs remotely, and the proposal says so.
Sales tax, accounting and payroll settings follow rules your CPA or tax adviser confirms. We configure Odoo; we do not give tax advice.
Customization is a last resort: each custom module is weighed against what it will cost at upgrade time, and delivered as source code you own once paid in full.
Meeting times, support hours and the go-live window are agreed in writing, with the time difference taken into account.
How the engagement runs
Central European time is six hours ahead of US Eastern time, so your morning overlaps with our afternoon. Meetings sit in that window; the rest is written.
Video workshops on your processes, entities, sales tax and data, closed by a written scope you approve.
Each area is configured on a test database and shown to the people who will use it, in recorded video demos.
Your data is loaded, and your team runs real orders, receipts and invoices through it before signing off.
Cutover in an agreed window, user training, then support and improvements under a written arrangement.
Frequently asked questions
Straight answers, including on the points where a remote partner differs from a local one.
No. Azinove Group has two companies, Azinove SAS in Strasbourg, France, and Azinove W.L.L in Bahrain, which is the group’s headquarters. We do not have a US office, a US entity or US clients we can name, and our engagements in the US do not include on-site work. What we offer instead is a process designed for remote delivery: written scoping, configuration demos by video, user acceptance on a test database and decisions kept in writing, so nothing depends on being in the same room.
Central European time is six hours ahead of US Eastern time, so a US morning lines up with a European afternoon. We schedule workshops, demos and acceptance sessions in that overlap and handle the rest asynchronously, through written notes and recorded videos your team can watch when it suits them. For companies further west the overlap is shorter, so we agree meeting times at the start of the project and put them in writing, along with support hours and the go-live window.
It can, but how depends on your situation. Some companies manage with Odoo’s own tax configuration and fiscal positions; others with obligations in many states are better served by a dedicated sales tax connector. We look at where you sell and ship, then choose the approach with you during scoping. Which states you owe tax in, and at what rates, is for your CPA or tax adviser to confirm. We configure Odoo to match their answer.
Nothing moves until we agree what is worth moving. Typically that means customers, vendors, products, open invoices and bills, and opening balances, with older transactions kept in an archive rather than imported line by line. We map each source file to Odoo, load it into a test database, and your team checks the numbers against the old system. The cutover date is usually set around a period close so the books carry over cleanly.
Yes. Odoo can hold several companies in one database, each with its own books, bank accounts, document numbering and currency, and give you a consolidated view across them. The decisions that matter are made at the start: which products, contacts and users are shared, how sales and purchases between your own companies are recorded, and what each entity reports. Those choices are hard to change later, so they go into the written scope before configuration begins.
Yes, in-house, but only when the standard modules cannot express a real business rule, such as a pricing method, a production step or an approval specific to your company. Every customization adds work at upgrade time, so we first check whether configuration or a well-maintained existing module does the job. When we do build, the module is written in Python, kept under version control and handed over as source code, which belongs to you once the project is paid in full.
Yes. For an older Odoo we start with a review of its configuration and custom code, then decide for each customization whether to keep it, replace it with a standard feature or drop it, before moving the data. For another ERP we map its data structure to Odoo and run test loads until the figures reconcile. In both cases your team validates the result on a test database before anything changes in production.
Odoo can run on Odoo’s own hosting or on a server or cloud account you control; if you need custom modules, that narrows the options, and we explain the trade-offs during scoping. The Odoo licence is a subscription with Odoo, separate from our implementation and support work, and our proposal states clearly which costs are ours and which are not. Backups, access and where the data sits are written into the engagement.
Your users are trained on their own workflows, using recorded sessions and short written guides they can return to. After launch we stay on under a written support arrangement covering fixes, questions, adjustments as the business changes and planning for future Odoo upgrades. Support hours are agreed with the time difference in mind. The same team that configured your system supports it, so you are not explaining your setup to someone new.
Let’s discuss the need
Tell us what runs on spreadsheets today, how many companies and states are involved, and which tools have to stay. We will tell you what standard Odoo covers, what needs scoping and whether a remote engagement fits.