Framework Agreement and Purchase Order: the Right Architecture for Clean Subcontracting

Introduction

You have a skilled tech freelancer, approved by your teams, but impossible to integrate cleanly into your supplier chain.

They are tax-resident outside the EU. They invoice from Dubai, Bali or another non-European jurisdiction. Your procurement department blocks the process. Your finance department asks for a French supplier. Your legal team wants a clear contractual architecture. Your end client requires compliance guarantees.

The issue is not merely administrative. It touches on contracts, subcontracting, invoicing, liability, VAT, due diligence and your IT services firm’s ability to secure an assignment without creating unnecessary risk.

In this context, the combination of a framework agreement and purchase order becomes central. If properly built, it separates the stable legal framework from each operational service. If poorly built, it creates grey areas: unclear deliverables, economic dependence, a fragile contractual chain, reclassification risk, and difficulty demonstrating compliance.

StelarWork intervenes precisely at this friction point. The French company (SASU) contracts in its own name with the IT services firm, invoices the IT services firm, contracts with the non-EU freelancer, carries the documentary compliance burden and turns a service provider who is difficult to sign directly into a French supplier that your procurement team can use.

Point to watch
This article provides a general operational view. It does not constitute personalised legal, tax or employment advice. Situations must be validated with your usual advisers depending on the countries concerned, the assignment, the contractual chain and the end client’s requirements.

Why the framework agreement and purchase order structure the relationship

A framework agreement sets the general rules of the relationship between two companies. It organises recurring obligations, responsibilities, confidentiality, intellectual property, invoicing terms, compliance rules, termination arrangements and the limits of the engagement.

The purchase order triggers a specific service. It describes the scope, deliverables, dates, milestones, day rate or price, validation arrangements, points of contact, special terms and the end client’s specific requirements.

For an IT services firm, this separation is useful. It avoids renegotiating all clauses for each assignment. It also makes it possible to document each service clearly, without turning the general contract into a shifting inventory of operational tasks.

In a chain involving a non-EU tech freelancer, this architecture is even more important. It shows that the IT services firm is purchasing a service from an identified supplier, not simply integrating a person into its operations without a framework.

The frequent problem for IT services firms: a good profile, but impossible to sign

IT services firms often face the same situation.

A cloud architect, senior developer, cybersecurity expert or data engineer genuinely works remotely from abroad. They have a local status. They are available, competent and aligned with the technical need. But they do not fit the IT services firm’s procurement boxes.

The blockers are familiar:

• non-EU supplier not listed in the supplier database;
• difficulty verifying local documents;
• uncertainty over applicable tax rules;
• refusal to pay a foreign invoice;
• doubts about subcontracting compliance;
• requirement for a French supplier;
• need for a contract aligned with the IT services firm’s standards;
• perceived risk regarding intellectual property and confidentiality;
• absence of a clear framework between the end client contract and the freelancer’s service.

As a result, the profile is technically approved, but the assignment does not move forward.

StelarWork then serves as a French B2B contractual interface. The IT services firm contracts with StelarWork. StelarWork then contracts in its own name with the non-EU freelancer. The relationship becomes clear for procurement, finance and legal teams.

Contractual architecture: what needs to be aligned

A sound contractual architecture rests on a simple idea: each contract level must be consistent with the level above it.

The IT services firm often has a main contract with its end client. That contract imposes obligations: confidentiality, security, intellectual property, compliance, deadlines, quality, reversibility, and sometimes requirements relating to location or approval of subcontractors.

If the IT services firm brings in a supplier, these obligations must be passed down through the subcontracting chain. This is the principle of contractual back-to-back arrangements.

The framework agreement and purchase order between the IT services firm and StelarWork must therefore enable this flow-down, without creating confusion about the nature of the relationship.

StelarWork does not act as the freelancer’s representative. StelarWork does not enter into a contract on behalf of the freelancer. StelarWork contracts in its own name with the IT services firm, then organises its own supplier relationship with the non-EU service provider.

This distinction matters. It helps avoid an ambiguous architecture, particularly in relation to permanent establishment, representation in France and contractual liability.

Key point
A good contractual architecture is not just about “having a contract”. It must prove who sells what, to whom, under whose responsibility, with which deliverables and under which compliance rules.

The role of the framework agreement

The framework agreement must contain the stable rules applicable to all services.

For an IT services firm, the most sensitive clauses are generally the following.

Purpose of the relationship

The purpose clause must describe a B2B service relationship. It must avoid wording that gives the impression of simply integrating staff into the organisation of the IT services firm or the end client.

The service must be linked to a need, a scope, deliverables, expertise or an expected outcome. The purchase order will then specify the operational details.

Responsibilities

The framework agreement must set out each party’s responsibilities.

The IT services firm carries its obligations towards its end client. StelarWork carries its supplier obligations towards the IT services firm. The non-EU freelancer remains bound to StelarWork by a separate contract.

This separation avoids mixing levels of responsibility. It gives procurement and legal teams a clear reading.

Confidentiality

Tech assignments often involve access to sensitive environments: source code, cloud architecture, internal data, product documentation, ticketing tools, Git repositories and testing environments.

The confidentiality clause must be robust and capable of being flowed down. It must cover the IT services firm’s information, the end client’s information and technical information obtained during the service.

Intellectual property

Intellectual property must be addressed explicitly.

The contract must provide for the conditions under which rights in the deliverables produced are assigned or transferred, within the limits of what is legally applicable. It must also organise the flow-down of necessary commitments in the contractual chain.

For an IT services firm, this point is critical. The end client often expects the deliverables to be usable without later challenge.

Compliance and documentation

The framework agreement must provide for the necessary documentary requirements: legal capacity, supplier identification, invoicing rules, tax compliance, international sanctions, anti-corruption, due diligence where relevant, and GDPR if personal data is processed.

In the case of a non-EU freelancer, StelarWork centralises this review and documentation logic in its supplier relationship. The IT services firm therefore has an identified French supplier, with a clearer chain.

Invoicing and payment

The framework agreement must specify the currency, invoice details, payment terms, dispute conditions, the link between validation of services and invoicing, and the treatment of applicable taxes.

Where cross-border services exist in the chain, the rules may involve specific mechanisms, including the VAT reverse charge depending on the case. These issues must be handled according to the real situation and validated by competent advisers.

For the IT services firm, the operational benefit is receiving a French supplier invoice from StelarWork within an identifiable B2B framework.

The role of the purchase order

The purchase order must not be a mere administrative document. It is the document that makes the service concrete.

It must specify what is being purchased, how the service will be monitored and on what basis it will be validated.

A robust purchase order generally contains:

• the title of the service;
• the context of the assignment;
• the functional or technical scope;
• the expected deliverables;
• the milestones or intervention periods;
• the day rate or pricing method;
• validation arrangements;
• project contacts;
• security constraints;
• the tools or environments concerned;
• confidentiality requirements;
• specific conditions imposed by the end client;
• the term and renewal arrangements;
• end-of-service conditions.

The objective is simple: to avoid the assignment resting solely on a person’s presence, ad hoc tickets or informal integration into the client’s teams.

The purchase order must document a service. Even when a day rate is used, it is preferable to link the engagement to a scope, deliverables, measurable contributions or assignment objectives.

Day rate and outcome-based service: how to avoid confusion

In the French IT market, the day rate is common practice. On its own, it is not enough to characterise the relationship.

The risk appears when the day rate becomes the only structuring element: one person, a schedule, a manager on the client side, daily tasks and no formalisation of deliverables or supplier responsibility.

A healthier approach consists of combining:

• a day rate as the economic mechanism;
• a service scope;
• expected deliverables or contributions;
• a validation process;
• contractual supplier responsibility;
• no reporting line between the IT services firm and the end service provider.

This approach helps the IT services firm document that it is purchasing a service, not simply an undefined human resource.

Good contractual reflex
The day rate is not a problem in itself. The issue is what it frames. A purchase order must describe an identifiable service, with expectations, limits and validation arrangements.

Subcontracting: what the IT services firm must be able to demonstrate

Subcontracting is not problematic when it is authorised, documented and consistent with the end client contract.

It becomes sensitive when the IT services firm cannot clearly explain who is involved, under which contract, with which obligations and under whose responsibility.

The IT services firm must be able to answer several questions:

• does the end client contract authorise subcontracting?
• is prior notification or approval required?
• are confidentiality obligations flowed down?
• do the end client’s security rules apply to the service provider?
• are intellectual property rights properly organised?
• is personal data processed?
• does the service provider genuinely work remotely?
• is the invoicing chain consistent?
• is the freelancer’s country of residence compatible with the end client’s constraints?
• have sanctions and compliance checks been carried out?

StelarWork aims to simplify this demonstration by becoming the IT services firm’s French contractual contact. The IT services firm does not have to create a direct relationship with a non-EU freelancer who is difficult to integrate into its supplier framework.

Compliance: points that must be addressed before the assignment

Compliance must not be added after the event. It must be built in from the construction of the framework agreement and purchase order.

Supplier identification

The IT services firm must know which entity it is contracting with. In the StelarWork model, the IT services firm’s supplier is a French company (SASU).

This approach facilitates supplier onboarding, invoicing, exchanges with procurement and alignment with the IT services firm’s internal standards.

Verification of the non-EU service provider

The fact that a freelancer is resident outside the EU is not enough to make the relationship acceptable. Basic elements must be checked: identity, ability to invoice, local status, real country of work, documentary consistency and absence of risk signals.

StelarWork handles this friction in its relationship with the service provider.

Genuine tax residence

One tax point must be recalled unambiguously: tax residence is not chosen on an invoice. It is demonstrated by reality.

A sound configuration notably requires genuine residence outside France, effective presence in the country concerned, activity genuinely carried out remotely and the absence of a stable organisation in France.

Conversely, an abusive configuration consists of using a shell entity or an artificial foreign address while the activity is in fact organised from France. This type of arrangement must be excluded.

StelarWork does not sell tax optimisation. The freelancer’s tax situation pre-exists the relationship. Where the freelancer is already genuinely tax-resident outside the EU and genuinely works remotely, StelarWork removes an administrative and contractual friction point for the IT services firm.

Permanent establishment

Permanent establishment risk may arise when a person or structure acts in an organised manner in one country on behalf of another entity, particularly by concluding contracts there or creating a characterised economic presence there.

In the StelarWork architecture, the distinction is essential: StelarWork does not conclude contracts on behalf of the freelancer. StelarWork contracts in its own name with the IT services firm.

This structure aims to avoid confusion between a French supplier, a non-EU freelancer and commercial representation in France. It must remain consistent in the documents and in practice.

Personal data and GDPR

IT assignments may involve access to personal data. The purchase order must identify whether the assignment gives the service provider exposure to such data.

Depending on the role of the parties, it may be necessary to include processing clauses, documented instructions, security measures, access restrictions and rules for returning or deleting data.

Examples must remain anonymised. No real name of a freelancer, IT services firm or end client should be used in operational documents where this is not necessary.

Unlawful labour lending: the risk to avoid in wording and in practice

The risk of unlawful labour lending appears when the arrangement looks less like a service provision and more like an unlawful supply of labour.

For an IT services firm, the issue is not limited to the words of the contract. Operational practices matter too.

Risk signals may include:

• absence of deliverables or scope;
• full integration into the end client’s organisation;
• daily control comparable to a reporting line;
• lack of autonomy in performance;
• invoicing linked only to presence;
• the supplier’s role reduced to administrative pass-through;
• confusion between contractual contacts.

A compliant architecture must move in the opposite direction: identified service, supplier responsibility, defined deliverables or contributions, validation of the service, and a clear B2B relationship.

StelarWork positions itself within this compliance logic. The model aims to structure a clean supplier relationship between the IT services firm and a French company, without creating an opaque chain or an uncontrolled direct relationship with a non-EU service provider.

Anonymised example: cloud assignment with a freelancer in Dubai

An IT services firm wins a cloud modernisation assignment for a French end client. It identifies a Terraform and AWS expert who is genuinely tax-resident in Dubai and works remotely from the United Arab Emirates.

The profile is technically approved. But the IT services firm does not want to onboard a foreign structure directly, nor handle alone the tax and contractual documentation relating to the service provider.

One possible architecture consists of setting up:

• a framework agreement between the IT services firm and StelarWork;
• a purchase order describing the cloud service;
• a separate contract between StelarWork and the freelancer;
• flowed-down confidentiality and intellectual property obligations;
• documentary verification of the service provider;
• invoicing by StelarWork to the IT services firm;
• invoicing by the freelancer to StelarWork under the applicable rules.

The purchase order is not limited to “senior cloud expert — 20 days”. It describes the expectations: review of the existing environment, Terraform modules, architecture documentation, migration support, validation criteria and security constraints.

The IT services firm therefore retains a clear structure for its procurement team, legal team and end client.

Anonymised example: full remote developer in Bali

An IT services firm supports a SaaS vendor in developing a backend module. The best available profile is a senior developer genuinely living in Indonesia and working fully remotely.

The difficulty is not the technical level. It is contractual: the end client requires a documented subcontracting chain, confidentiality commitments, an assignment of rights in the code produced and invoicing compliant with the IT services firm’s standards.

The framework agreement and purchase order make it possible to structure the engagement.

The framework agreement sets the general rules. The purchase order specifies the module concerned, expected deliverables, milestones, code review rules, accessible environments and acceptance criteria.

StelarWork becomes the IT services firm’s French supplier. The freelancer remains StelarWork’s non-EU service provider, in a separate relationship.

This architecture does not transform the developer’s tax residence. It simply makes the relationship usable for the IT services firm, provided that the residence and remote work match reality.

Clauses to watch in a framework agreement and purchase order

For an IT services firm, certain clauses deserve particular attention.

Purpose clause

It must refer to a service provision. It must avoid any ambiguity regarding a relationship of subordination, permanent integration or mere supply of human time.

Ordering clause

It must provide that each assignment is covered by a separate purchase order, with a specific scope and conditions.

Validation clause

It must indicate how services are accepted: validation of deliverables, report, milestone, activity statement consistent with the service, validation by the project manager.

Subcontracting clause

It must be consistent with the end client contract. It may provide for the conditions under which third-party service providers intervene, flowed-down obligations and documentary requirements.

Compliance clause

It must cover the reasonable checks expected: legal capacity, sanctions, anti-corruption, applicable tax rules, security, confidentiality and data protection.

Intellectual property clause

It must organise the use of the deliverables by the IT services firm and, where applicable, by the end client. Rights must be flowed down in the chain where necessary.

Security clause

It must govern access to systems, authentication, authorised tools, storage rules, access management and the return of information at the end of the assignment.

Non-representation clause

It may recall that each party contracts in its own name. This clarification limits confusion over any potential authority to represent another party.

Tax clause

It must remain factual. It must not promise a tax outcome. It may recall that each party remains responsible for its own tax obligations and that the applicable mechanisms depend on the reality of the situation.

Mistakes to avoid

Certain mistakes seriously weaken the relationship.

Using an overly vague purchase order

A purchase order containing only a profile name, a day rate and a duration is not always enough to demonstrate a structured service.

You need to add the context, scope, expectations, validation arrangements and applicable constraints.

Copying the end client contract without adaptation

Back-to-back arrangements are useful, but they must not be mechanical. Some clauses in the end client contract are not suited to the supplier relationship. They must be flowed down intelligently.

Ignoring the freelancer’s tax reality

A foreign address is not enough. There must be genuine residence, activity genuinely carried out outside France and no organised presence in France.

A shell entity used to conceal a French activity is an abusive configuration.

Creating confusion over representation

The French supplier must not be presented as concluding contracts on behalf of the non-EU freelancer. It contracts in its own name.

This precision protects the clarity of the chain and reduces the risks of incorrect qualification.

Allowing the end client to manage the relationship directly like a manager

Project coordination is normal. A hierarchical relationship is not.

The purchase order must preserve a service logic, with deliverables, milestones and contractual validation.

Operational checklist for an IT services firm

Before launching an assignment with a non-EU tech freelancer through a French supplier architecture, you can check the following points.

Framework agreement side

• The parties are clearly identified.
• The purpose describes a B2B service.
• Responsibilities are allocated.
• Invoicing terms are provided for.
• Confidentiality clauses are adapted.
• Intellectual property is organised.
• Compliance requirements are documented.
• Subcontracting is framed.
• GDPR rules are provided for if necessary.
• Each party contracts in its own name.

Purchase order side

• The assignment context is described.
• The deliverables are identified.
• The scope is limited.
• The day rate or price is stated.
• The milestones are specified.
• Validation arrangements are provided for.
• Security constraints are listed.
• Access to tools is governed.
• The end client’s obligations are included where necessary.
• The duration and end conditions are clear.

Compliance side

• The freelancer genuinely works outside France.
• Their tax residence is consistent with their real situation.
• Supplier documentation is collected.
• Sanctions and anti-corruption risks are checked.
• Personal data is identified if the assignment gives access to it.
• Tax obligations are not based on a fiction.
• The contractual chain remains clear for procurement, legal and the end client.

Where StelarWork fits into this architecture

StelarWork fits between the French IT services firm and the tech freelancer based outside the EU.

In practice:

• StelarWork signs with the IT services firm in its own name;
• StelarWork invoices the IT services firm;
• StelarWork contracts separately with the freelancer;
• StelarWork pays the freelancer under the established supplier relationship;
• StelarWork handles the documentary and compliance friction;
• the IT services firm has a French supplier that is easier to onboard.

The model meets a specific need: making an international profile usable where the IT services firm cannot sign them directly under good internal conditions.

It is not about selling a tax residence or creating artificial optimisation. Where the freelancer is already genuinely tax-resident outside the EU and genuinely works remotely, StelarWork primarily removes a contractual, administrative and supplier obstacle for the IT services firm.

Why this approach reassures procurement and legal teams

Procurement wants an identifiable supplier, a usable invoice, a clear contract and controlled risk.

Legal wants a coherent chain, flowed-down obligations, clear responsibility and no artificial arrangement.

Finance wants to know who invoices, under which rules and with which supporting documents.

Delivery wants to start the assignment without losing the profile.

The framework agreement and purchase order make it possible to bring these requirements together in an architecture that is simple to understand. StelarWork provides the French contractual link that is often missing between the IT services firm and the non-EU freelancer.

This approach does not remove the need for analysis. It aims to reduce friction and make the relationship defensible, documented and operational.

FAQ

What is the purpose of a framework agreement in an IT services firm–supplier relationship?

The framework agreement sets the general rules of the relationship: responsibilities, confidentiality, intellectual property, invoicing terms, compliance, termination and ordering arrangements. It avoids renegotiating these clauses for each assignment.

What is the purpose of the purchase order?

The purchase order triggers a specific service. It describes the scope, deliverables, duration, day rate or price, validation arrangements and specific constraints of the assignment.

Why combine a framework agreement and purchase order?

The framework agreement provides legal stability. The purchase order provides operational precision. Together, they create a contractual architecture that is clearer and better suited to recurring assignments.

Can an IT services firm work with a non-EU freelancer?

Yes, but the relationship must be structured. Invoicing, compliance, tax, subcontracting, confidentiality, intellectual property and genuine residence must be addressed. Some IT services firms prefer to go through a French supplier such as StelarWork to secure their internal chain.

Does StelarWork sign on behalf of the freelancer?

No. StelarWork contracts in its own name with the IT services firm. The non-EU freelancer is bound to StelarWork by a separate contract. This distinction is essential to avoid confusion over representation.

Does the freelancer become a direct supplier of the IT services firm?

No. In this model, the IT services firm’s supplier is StelarWork. The IT services firm receives an invoice from StelarWork and deals with a French company. The freelancer operates within StelarWork’s contractual chain.

Is the day rate compatible with a compliant service?

Yes, if the day rate is only a pricing mechanism. The purchase order must also describe a service, deliverables, a scope and validation arrangements.

What are the main risks to avoid?

The main risks are unauthorised subcontracting, unclear deliverables, confusion over responsibility, fictitious tax residence, lack of documentation, uncontrolled processing of personal data and practices resembling supply of labour without a defined service.

Does StelarWork allow the freelancer to pay less tax?

No. That is not the purpose. The freelancer’s tax situation must be real and pre-existing. If the freelancer is genuinely tax-resident outside the EU, genuinely works from abroad and has no organised presence in France, StelarWork can remove administrative friction for the IT services firm. An artificial entity or façade address would be an abusive configuration to exclude.

Are the framework agreement and purchase order enough to guarantee compliance?

No. They are essential, but practices must follow. The assignment must remain organised as a service, with deliverables, supplier responsibility, consistent documentation and no artificial arrangement.

Conclusion

The framework agreement and purchase order are not mere procurement formalities. For an IT services firm that wants to work with a non-EU tech freelancer, they structure the relationship, document the service and reduce grey areas.

The key is to build a coherent contractual architecture: an identified French supplier, a described service, flowed-down obligations, verifiable compliance and tax reality respected.

StelarWork meets this need when the IT services firm has approved an international profile but cannot sign them directly. The relationship becomes clearer for procurement, legal, finance and the end client, without creating any contractual or tax fiction.