Subcontracting Odoo development inside the EU: what changes in the contract, the GDPR, the invoice and the courts

When the Odoo subcontractor is inside the EU, four things change, and all four can be checked before you sign. The Article 28 GDPR processor contract is signed without triggering Chapter V: the client's data never leaves the European Economic Area. The invoice is an intra-EU B2B service, with no supplier VAT and reverse charge under Article 196 of Directive 2006/112/EC. The working day is the same: Barcelona is on CET/CEST, like Amsterdam, Berlin or Stockholm. And the contract runs under a Member State's law, enforced in its courts. None of it depends on goodwill: it depends on where the supplier is.

GDPR in practice: Article 28 and the data that actually leaves

Your end client is the controller (Art. 4(7) GDPR), you are its processor (Art. 4(8)) and the subcontractor is a sub-processor. Watch who does the authorising: Art. 28(2) requires “prior specific or general written authorisation of the controller”. The client authorises, not you: either you ask for it, or you carry it already signed as a general authorisation. The sub-processing contract must carry the same obligations as your contract with the client (Art. 28(4)): subject matter, duration, nature and type of data in the opening of Art. 28(3), and in its points (a) to (h) documented instructions, confidentiality, Art. 32 security, data-subject rights, deletion or return at the end, and audit. A non-EU sub-processor adds Chapter V on top (Arts. 44 to 50): an adequacy decision (Art. 45), standard contractual clauses (Art. 46), a transfer impact assessment. With one in Spain, that block does not exist.

What almost nobody writes into the DPA is which data actually leaves in an Odoo build. From experience, these:

• Production copies on staging or on a build: contacts, invoices, payroll if HR is installed, the full chatter.
• Logs from Odoo.sh and the server, with email addresses, names and tracebacks carrying record data.
• Attachments (ir.attachment): invoice PDFs, signed contracts and identity documents.
• Third-party credentials in ir.config_parameter: marketplace, carrier and payment-gateway keys.

Keeping that inside the EU depends on what Odoo.sh allows. Its official FAQ states that the platform runs on Google Cloud data centres and that the European zone is Saint-Ghislain, Belgium; that a project's region cannot be changed; that development builds are “a completely independent deployment” that “may be processed in another zone”; and that locations “are not contractually guaranteed”. So the subcontractor works on the partner's or the client's own Odoo.sh project, in its region, with its own revocable user, not on a copy of ours. If real data is needed, the case is reproduced on a build of that project and the build is destroyed.

Time zone: what changes in reviews and incidents

Barcelona is on CET/CEST: the same clock as Benelux, Germany, Austria, Switzerland, France, Denmark, Sweden and Norway; one hour behind Finland and the Baltics; one ahead of Ireland and Portugal. We promise no response times, but a shared clock changes the mechanics:

• Same-day review. A pull request opened in the morning is commented on and fixed in the afternoon. With a six-hour offset, every round costs a day.
• Incidents while the client is awake. The failure is seen at the hour the warehouse suffers it and can be reproduced live.

Invoicing: an intra-EU B2B service under the reverse charge

Software development is a service. Between businesses in two Member States the place of supply is the customer's seat (Art. 44 of Directive 2006/112/EC) and the customer owes the VAT (Art. 196). The subcontractor invoices without VAT, with the mandatory “Reverse charge” mention (Art. 226(11a)) and both VAT numbers, and reports it on its recapitulative statement (Art. 262; in Spain, Modelo 349). You self-account for it, input and output VAT in the same return. What to ask for:

Governing law, jurisdiction and ownership of the code

Two EU companies choose the law of the contract (Art. 3, Rome I, 593/2008) and the competent court (Art. 25, Brussels I bis, 1215/2012). What makes the choice useful is Art. 39 of Brussels I bis: a judgment given in one Member State is enforceable in the others with no declaration of enforceability. Outside the EU the paper says the same; what changes is the cost of making it stick. We sign under Spanish law and the courts of Barcelona, or the partner's: what matters is that it is enforceable, not that it is ours.

On the code: Art. 97.4 of the Spanish Intellectual Property Act gives the employer the economic rights in a program written by an employee in the course of their duties, and only “unless agreed otherwise”; it speaks of employees and does not reach a contractor. If the subcontractor is another company, ownership passes to you only through an express assignment clause; without it the author keeps the rights and you hold, at most, an implied licence. And the assignment has to fit the module's licence: depending on third-party LGPL-3 code carries that licence with it whatever the contract says. The detail is in who signs the module.

Who signs the module before Odoo: three models

In the Odoo partner agreement (version 11, dated 19 May 2023) the word “subcontract” never appears: it regulates access to the Enterprise source, the brand and the client's point of contact. Its clause 3.2 does bind you, though: confidentiality of the Odoo Enterprise source is kept “within its staff”, and that code is not redistributed to third parties without Odoo's written permission. If the subcontractor is going to touch Enterprise code, settle that before you start. The authorship model is what you write into your contract, and there are three:

• White label. The module carries your name and lives in your repository; the subcontractor is invisible. It needs an express assignment and confidentiality over the relationship.
• Visible supplier. The subcontractor publishes the module under its own name and you implement it: it is what we do with connectors for technology partners.
• Extended team. Our engineers in your repository, with your process and your review; you are the author. That is Odoo engineering for consultancies.

None is better in the abstract: what matters is that the contract says which one, because it decides who answers to the client and who ports to the next version. All three leave you as the client's partner, and that is how our partner programme.

How to verify delivery: a real Odoo.sh build, not screenshots

Everything above is paper; what protects the project is delivery. The only proof we accept of a module is that it installs and passes its tests on a real Odoo.sh build of every version it must support: it ships on 19, 18 and 17 only with the three green. A screenshot proves something worked once; a linked build proves it works today where it will live. Ask for the link and ask to see the tests, because a green suite that tests nothing is worse than none: our own cases here, and the process in publishing a module.

Six questions before you sign

1. Which company signs, under which tax ID, and is its VAT number on VIES? A brand is nobody.
2. Where does the code run and where is the data? The answer names an Odoo.sh project and a region, not “our servers”.
3. Are there sub-processors underneath? Freelancers, ticketing, AI tools. None can be engaged without the controller's written authorisation (Art. 28(2)): ask for the list.
4. Who is the author and who holds the repository? White label, visible supplier or extended team, in writing.
5. Which law and which courts? A Member State's, so Brussels I bis can do its job.
6. What is the proof of delivery? A build link per version, tests visible.

With those six in writing, the rest is the usual: scope, milestones, maintenance and who ports it (services).

Frequently asked questions

Useful links inside FlexigoTech

What we do about this