The 2026 Technical Annex
Ten Technical Questions the Core Vetting Kit Does Not Reach
Why These Ten
The Core Vetting Kit was designed to filter on integrity and method: did the partner do upgrades, did they push back on customization, did they design data ownership into the engagement. Those filters work because most failures trace to those disciplines.
These ten questions filter on something different: technical depth. They probe whether the partner has actually engineered Odoo deployments at scale, or whether they have built configurations that happen to work in dev and pray in production. They surface the architectural choices, regulatory positions, commercial framing, and upgrade-safety commitments that distinguish a 2026 Odoo practice from a generic ERP consultancy.
Several of these questions ask about Odoo 19, the September 2025 release. Most production deployments are still on Odoo 17 or 18 as of this writing, so partners may not yet have v19 production references. That is fine. What matters is whether they have a credible roadmap and have engaged with the architectural shifts the new version introduces.
Technical Architecture
The Core covered hosting, environments, CI/CD, third-party app vetting, and integration architecture. These five additions probe deeper into the technical disciplines a 2026-grade Odoo partner needs.
Performance and load testing
At what concurrent user count have you seen Odoo performance degrade in production, and on what hosting tier? Show me a load test report from a previous client at similar scale to ours. How do you instrument response-time SLAs, and what is your remediation playbook when the system slows below threshold? For our scale specifically, what is your documented 95th percentile response time for the three operations that matter most: sales order save, invoice posting, and the largest report we will run? At 50 concurrent users and 100,000 transactions per day (typical SME), what numbers should we expect?
Many Odoo deployments fail not on functionality but on speed. The partner who has never measured response times under realistic load cannot promise you they will hold up under yours. Performance degradation is also the failure mode where the partner most reliably blames the customer ("you have too much data," "your users click too fast") because there is rarely a documented baseline to refute them. Asking for specific 95th-percentile numbers at named transaction volumes forces the partner to commit to a measurable target before signing.
Documented load test results from at least one comparable client. Named thresholds (database connections, mail queue throughput, cron timing). Concrete numbers for 95th percentile response times on common operations (sub-2-second sales order save and invoice posting at 50 concurrent users is a reasonable benchmark on Odoo.sh standard tier). Response-time monitoring instrumented from go-live. Concrete remediation steps the partner has taken in past incidents (caching layer, query optimization, server resize).
"We have not had performance issues." Translation: they have not measured. Or: "Performance is Odoo's responsibility." Translation: they will blame the platform when your users complain. Or vague numbers like "fast enough" without a percentile commitment.
Multi-company, inter-company, and multi-currency revaluation
For multi-company setups (especially holding structures or trading groups operating in multiple currencies), how do you handle inter-company invoicing, transfer pricing, automatic eliminations, and consolidated financial statements? How do you configure month-end currency revaluation for foreign-currency receivables and payables? Show me a working example from a previous client.
Multi-company is one of the highest-stakes configuration areas in Odoo, and one of the most commonly misconfigured. UAE holding structures with multiple operating entities, GCC trading groups with regional offices, family businesses with separate legal entities for tax efficiency: all of them depend on inter-company transactions working cleanly. Mistakes here surface as reconciliation pain at month-end and audit findings at year-end. Odoo 19 expanded inter-company transaction support, so partners should have updated answers.
Demonstrated experience with at least one multi-company implementation. Working example of inter-company invoicing with automatic mirror entries. Configured currency revaluation with documented period-end procedures. Knowledge of Odoo's account_consolidation module or equivalent for consolidated statements.
"We have not done multi-company before but we are confident we can figure it out." For UAE holdings, this is a 50,000 USD answer that turns into a 200,000 USD project.
Odoo Studio versus Python modules
Under what circumstances do you use Odoo Studio versus writing proper Python modules? What are the upgrade consequences of each approach, and how do you document and version-control Studio customizations? Show me your team's split between Studio work and proper module development over the last twelve months.
Odoo Studio is excellent for small SMEs that need quick adjustments and have no developer access. It is also a frequent cause of upgrade nightmares because Studio changes live in the database, not in version control, and they do not always survive major upgrades cleanly. Partners who default to Studio for everything are typically optimizing for short-term cost over long-term maintainability. Partners who write proper modules for everything are over-engineering small problems. The right partner has a defensible philosophy on when to use which.
Articulated criteria for Studio versus Python decisions. Studio used for genuinely small, scoped changes (renaming a field, adding a simple computed field, customizing a report layout). Proper Python modules for any business logic, automation, or anything that needs to survive multiple upgrades. Studio changes documented and reviewable in writing even though they live outside Git.
"Studio is great, we use it for everything." Or: "We never use Studio, only Python." Both extremes are warning signs of a partner who has not thought about the trade-off.
Odoo 19 readiness and architectural transitions
What is your roadmap for adopting Odoo 19's architectural changes: the OWL front-end framework, the restructured module loading (30 to 50 percent faster installation, 50 percent faster updates), and the new inter-company transaction model? What is your migration plan for existing clients from Odoo 17 or 18 to 19, and how do you handle custom modules that depend on the old front-end framework?
Odoo 19 introduced architectural changes that go beyond feature additions. The OWL framework migration affects every custom widget and view. The module loading restructure changes how partners think about installation and upgrade timing. Partners who have not engaged with these shifts will produce code that breaks on the next major upgrade. The question is not "do you have a v19 production deployment yet" (most do not). The question is "have you thought about it seriously."
Documented adoption plan with timelines. Internal training completed or scheduled on OWL framework. Test migrations of representative custom modules to v19 already run on staging. Honest acknowledgment of what works and what does not yet.
"We will figure out v19 when our clients ask for it." That is two years of upgrade debt the partner is planning to bill you for later.
AI integration and the realistic state of practice
Odoo 19 ships with native LLM integration (natural language prompts to update records, AI-generated Studio content, integrated chatbot in Chatter and Helpdesk). How are you using these features with current clients? For more advanced scenarios: do you have experience integrating Retrieval-Augmented Generation over the Odoo Knowledge base, or LLM-assisted workflows for customer service and operations? What is your honest assessment of where this technology is genuinely useful versus where it is hype?
AI integration in Odoo is real but the partner bench depth on it is shallow in 2026. Asking this question filters serious technical partners from theatrical ones. A partner who claims fluent RAG experience but cannot explain vector embeddings or retrieval pipelines is bluffing. A partner who says "we are watching this carefully and have done internal experiments but are not yet recommending it to clients at scale" is being honest and probably correct.
Hands-on experience with Odoo 19 AI features. Realistic assessment of LLM strengths (summarization, draft generation, classification) and weaknesses (accuracy on regulated content, hallucination on numerical data). For partners claiming RAG experience: ability to explain the architecture, including vector database choice, embedding model, retrieval evaluation. Pragmatic posture: AI as augmentation, not replacement, with human-in-the-loop on anything that matters.
Buzzword answers without specifics. Promises of "AI-powered everything." Or the opposite: complete dismissal of AI as a fad. Both signal a partner who has not engaged with the actual state of the technology. Note: "We are still evaluating and not yet ready to recommend it" is an acceptable answer for SMEs in 2026. The bar here is honesty about state of practice, not necessarily current capability.
Security and Compliance
The Core covered RBAC, audit trails, regional compliance, backups, and Segregation of Duties. These three additions probe regional and architectural depth.
Arabic UI, RTL rendering, Hijri dates, and bilingual reporting
For deployments serving KSA government clients or bilingual GCC operations: how do you configure right-to-left (RTL) rendering across all standard and custom modules? How do you handle Hijri dates alongside Gregorian for invoices, contracts, and reports? Can you generate bilingual reports (Arabic and English) on the same invoice or sales order? Show me an example in production.
Saudi government clients and many UAE holding groups require bilingual Arabic-English reporting on every commercial document. KSA's ZATCA Phase 2 e-invoicing mandate further requires Arabic-compliant invoice rendering. Partners building for these markets without fluent Arabic and Hijri experience will produce deployments that pass internal UAT but fail regulatory acceptance. This is the kind of gap that surfaces at submission to a government portal, not before.
Production references with bilingual rendering. Familiarity with Odoo's RTL CSS and how it interacts with custom views. Working Hijri date implementation, ideally through a documented OCA module or partner-maintained extension. Arabic-fluent team members involved in UAT.
"We have not done Arabic UI but we can probably make it work." Or: "Odoo supports Arabic out of the box, so it should be fine." Both signal naive optimism about a regulatory-sensitive area.
Data residency and physical hosting location
Where will the production database physically reside? Which data center, which legal jurisdiction, and what is the cross-border data transfer mechanism for backups, monitoring, and support access? How does this satisfy UAE PDPL, Saudi PDPL, banking secrecy requirements (for financial services clients), and our internal data residency policy?
Data residency is the regulatory question that quietly determines hosting architecture. Odoo Online defaults to EU/US hosting. Odoo.sh has multi-region options but they require deliberate selection. Self-hosted in a UAE data center is a common requirement for government, banking, and healthcare clients in the region. PDPL enforcement (UAE: January 2027 full enforcement, fines up to AED 5 million) is increasing the cost of getting this wrong.
Specific answer naming the data center, the region, and the legal jurisdiction. Documented cross-border transfer mechanism with proper consent or contractual basis. Demonstrated experience hosting Odoo in UAE-based or KSA-based data centers if regulatory requirements demand it. Awareness of the difference between data residency (where the data lives) and data sovereignty (who has legal access).
"Odoo handles hosting." Translation: they do not know where the data lives. Or vague answers about "secure cloud hosting" without naming the data center. For regulated industries, this is a disqualifier.
Fiscal period closing, lock dates, and multi-period reconciliation
How do you configure fiscal year closing, accounting lock dates, and tax lock dates in Odoo? How do you handle period-end reconciliation when our books need to close monthly with auditor sign-off? Show me a multi-period closing from a live client, including how locked periods are protected from accidental edits and how reversing journals are managed across the lock boundary.
Period closing is where Odoo finance implementations break under audit pressure. Odoo has lock_date and tax_lock_date fields specifically designed for this, but partners who do not configure them properly leave the books permanently editable, which auditors will not accept. Customizations that interfere with account.move reconciliation create the kind of subtle accounting errors that surface six months later, traced back to the implementation. The partner who has lived through a multi-period audit in production knows what this question is about. The partner who has not will give vague answers.
Documented use of lock_date and tax_lock_date from go-live. Concrete example of a live client closing monthly with auditor sign-off. Configured controls for reversing journals across locked periods. Familiarity with the auditor's perspective on what good Odoo accounting controls look like.
"Odoo handles period closing automatically." It does not, not without configuration. Or "we will sort it out after go-live." Doing this after go-live is significantly more expensive than doing it before.
Commercial and Edition Strategy
The Core covered pricing model, custom code ownership, and exit terms. These additions probe the edition strategy that determines your three-year cost, and the upgrade-safety clause that determines whether your custom code will survive the next major release.
Three-year total cost: Enterprise versus Community versus OCA
For our scope specifically, build me a three-year total cost of ownership comparison across three scenarios: Odoo Enterprise with your implementation, Odoo Community supplemented by OCA modules with your implementation, and Odoo Community with custom-built equivalents for the features Enterprise ships natively. Which Enterprise modules are genuinely required for our needs, and which Enterprise features are also available in OCA?
The Enterprise versus Community decision is loaded for partners. Odoo SA partnership agreements restrict official partners from recommending Community as a primary path, which means most partners default to Enterprise even when Community plus OCA modules would serve the customer better. Asking for a three-year TCO comparison reframes the question into something a partner can answer without violating their agreement: "here is what each scenario actually costs you over three years." The partner who delivers a real comparison is doing genuine advisory work. The partner who refuses or produces a comparison that obviously favors Enterprise on every dimension is selling, not advising.
A real three-scenario TCO model with license costs, implementation costs, ongoing maintenance, and feature-gap remediation costs all itemized. Honest assessment of which Enterprise features are also in OCA (CRM enhancements, accounting reports, project management, marketing automation are commonly available). Honest assessment of where Enterprise genuinely wins (Studio, Sign, Documents OCR, official localization packs for some countries).
Refusal to do the comparison. Or a comparison where Community scores worse on every dimension including ones where OCA modules clearly close the gap. Or: "Community is for hobbyists; serious businesses use Enterprise." That is the sales pitch, not the advisory answer.
The Migration Proof Clause
Will you commit, in the contract, that every custom module you deliver passes the odoo-bin upgrade test for the next major Odoo version before final acceptance? In other words, before we accept and pay for the module, you demonstrate that it does not depend on deprecated APIs, removed fields, or libraries scheduled for removal in the next release. How do you certify this, and what is your remediation if a module fails the test post-delivery?
This single clause is the most effective protection against upgrade-cliff debt. Odoo ships odoo-bin upgrade as a tool for testing migration compatibility, but most partners never run it as part of their delivery pipeline. The result: custom modules accepted today break when you try to move from Odoo 18 to 19, and the partner bills you for the rewrite. A contractual Migration Proof clause forces the partner to write upgrade-safe code from day one or absorb the cost of cleaning it up later. The partner who pushes back hardest on this clause is telling you exactly how much rework they were planning to bill for.
Willing to write the clause into the contract. Has a documented process for running odoo-bin upgrade and Odoo's deprecation warnings as part of their CI pipeline. Concrete example of a module they refactored to pass the test before delivery. Acknowledges that some Odoo SA changes are unannounced, and offers a fair remediation policy (partner absorbs costs from deprecations that were documented; customer pays for breakage caused by genuinely surprise changes).
Refusal to commit in writing. "We always write upgrade-safe code" without process to back it up. Or insistence that upgrade compatibility cannot be tested until the next version actually ships, which is technically true for surprise changes but evasive for the 90% of deprecations that are documented in advance.
How to Use This Annex
Treat these ten questions as the technical layer beneath the Core's 33. Run them with the same shortlisted partners, in the same two-hour technical session, but with the IT lead carrying the conversation rather than the project sponsor. Score them on the same Green/Yellow/Red scale.
Three of these questions deserve weighting as "deal-shapers" rather than "deal-breakers": B9 (Odoo 19 readiness), B10 (AI integration), and E4 (edition TCO). A partner can be excellent without yet having Odoo 19 production references, without RAG experience, or without offering a Community-positive TCO comparison. But the quality of their answer to these three questions tells you whether they are thinking about the next five years of your engagement or only the next six months.
The other seven (B6 performance, B7 multi-company, B8 Studio versus Python, C6 Arabic/RTL, C7 data residency, C8 period closing, E5 Migration Proof) are deal-breakers for the right buyer. If your scope is purely single-company, English-only, non-regulated, lightly customized, you can ignore some of them. If your scope involves UAE holding structures, KSA government clients, regulated industries, multi-period audited closings, or any custom development at all, every one of them is non-negotiable. E5 in particular should be in every contract regardless of scope.
Add These to the Scorecard
The companion scorecard for the Core kit scores 33 questions across six categories. The ten questions in this annex slot into the same scoring framework. Add them to your scorecard with weights of 1 (B6, B7, B8, C6, C7, C8), 2 (B9, B10, E4 as deal-shapers), or 3 (E5 Migration Proof as a contract-grade requirement worth high weight). None of these are auto-disqualifiers in the way Q1, Q2, A1, A3, and E2 are in the Core. But a partner who lands four or more Red flags across the ten is not equipped for a 2026 implementation, regardless of how well they scored on the Core.
The Core kit filters for integrity and method. This annex filters for technical depth. Use both together for any partner engagement above 100,000 USD or beyond a single legal entity.
This checklist is a working document. Real Odoo implementations surface patterns no general checklist anticipates. Capture what you learn in your own diligence and add it to this kit. The next buyer benefits.