REPSE in Mexico: What Software Outsourcing Buyers Must Verify

REPSE is Mexico's public registry for providers of specialized services or works. Software outsourcing buyers must assess the vendor's certificate and registered scope together with the actual service, worker-disposition facts, contract, and supporting filings under Mexico's specialized-services rules.

Managed software projects, staff augmentation, and employer-of-record arrangements can produce different REPSE conclusions. The analysis follows who employs the people, who directs them, what the buyer's business is, where the work sits in that business, and how the service is performed.

The legal and agency sources were checked on August 14, 2026. Obtain qualified Mexican legal and tax advice for the specific arrangement.

What REPSE means in Mexico

REPSE stands for Registro de Prestadoras de Servicios Especializados u Obras Especializadas. The Secretaría del Trabajo y Previsión Social operates the registration platform and public register.

The current framework begins with four Federal Labor Law rules:

• Article 12 prohibits personnel subcontracting—the provision or placement of a contractor's workers for the benefit of another party.

• Article 13 permits specialized services or works that are outside the beneficiary's corporate purpose and predominant economic activity, subject to the statutory conditions.

• Article 14 requires a written contract describing the service or work and the approximate number of workers involved. It also creates joint liability for the beneficiary when the contractor fails to meet worker obligations arising from the arrangement.

• Article 15 requires the specialized-services provider to register with the STPS and renew its registration periodically.

These REPSE rules operate alongside Mexico employment law, payroll, tax, and social-security requirements, so valid registration answers only one part of the buyer's compliance question.

The official REPSE FAQ describes registration as applying when a provider supplies specialized services or works and places its own employees at a third party's disposal, and it ties permitted specialized services to work outside the beneficiary's corporate purpose and predominant activity.

The test applies to both the work and the arrangement. Evaluate specialization and contract fit from the service and arrangement rather than the word “software.”

The REPSE qualification test for software services

Buyers comparing software development companies should begin with how the engagement will operate.

1. Are the provider's workers placed at the buyer's disposal?

Relevant facts include:

• who assigns daily tasks and priorities;

• who sets schedules, working locations, leave, and on-call duties;

• whether people are embedded in the buyer's organizational structure;

• who supervises performance and can demand replacement;

• whether the provider controls staffing, method, and sequencing;

• who owns the delivery plan and accepts the result;

• whether the buyer purchases individual capacity or a defined outcome; and

• where the work is performed and whose premises or systems are used.

The STPS FAQ discusses worker disposition by reference to employees working at another company's premises. Remote and hybrid software delivery can create different facts. Document location, supervision, authority, integration, deliverables, and actual management.

2. Is the service outside the buyer's corporate purpose and predominant activity?

Review the buyer's current corporate documents, tax registration, actual operation, and contracted scope. A generic statement that “technology is specialized” does not answer whether the work sits inside the beneficiary's purpose or main economic activity.

An internal application for a retailer, platform engineering for a software company, cybersecurity monitoring for a bank, and a provider-owned implementation project each require their own analysis.

3. Does the provider's REPSE registration cover this work?

Match the contracted service with the authorized description in the public register. Confirm the legal entity, RFC, registration number, validity, and renewal date. A registration held by an affiliate does not automatically cover the entity signing the agreement or employing the workers.

If any part of the analysis is unclear, stop before contracting. A commercial deadline is not a legal conclusion.

How common software-delivery models change the analysis

The first risk signal comes from the operating model: who manages the people and who owns the delivery result.

Apply the same entity and control analysis to an employer of record in Mexico.

The distinction between staff augmentation and a managed-delivery model matters for nearshore software development in Mexico. A statement of work framed around milestones will not create outcome ownership if the buyer actually manages each vendor employee.

REPSE registration scope, validity, and cancellation

Use the official public register to identify the provider. Preserve a dated copy of the result showing:

• the exact registered legal name;

• RFC;

• registration or filing number;

• current validity;

• authorized specialized service or work descriptions;

• issue and expiry information; and

• the date the buyer checked it.

REPSE registration is renewed every three years, during the three months before expiry. Recheck it at onboarding, renewal, material scope changes, entity changes, and before relying on it for a tax period.

Updates and modifications leave the three-year period unchanged; renewal remains mandatory. The provider also needs to remain current on its tax and social-security obligations. The REPSE platform checks compliance information supplied by SAT, IMSS, and INFONAVIT when an application is made.

Registration can be cancelled before expiry

STPS identifies several cancellation grounds that matter to a buyer. Some concern the service itself: providing an unregistered service or performing work inside the beneficiary's corporate purpose or predominant economic activity. Others concern provider compliance, including tax or social-security debt and failure to maintain registration requirements, answer an STPS information request, or renew. False or inaccurate information and worker-registration or service-contract irregularities are additional grounds.

Check the active register and the cancelled-provider information, then file the search results with the certificate supplied during procurement. The contract should require prompt notice of an STPS, SAT, IMSS, or INFONAVIT issue that could affect registration, plus suspension and exit rights if the registration no longer supports the service.

Require the provider to identify the legal entity that employs the workers and map the registered service to the contract. Warning signs include:

• the sales brand appears in the proposal but a different entity employs the team;

• the registered service description is broader or unrelated to the statement of work;

• registration is near expiry with no renewal evidence;

• the provider offers another group company's registration;

• the workforce count and delivery locations are unclear; or

• the provider treats REPSE as proof that the buyer can direct any work it wants.

What the REPSE contract must show

Article 14 requires the specialized service or work and approximate worker count to be stated in writing, but the buyer needs more than the statutory minimum to control a software engagement.

The contract should cover each of the following operational and evidence requirements:

• legal names, RFCs, and contracting roles;

• the specialized service or work, exclusions, and objective deliverables;

• approximate worker count and covered locations;

• provider management and buyer governance;

• who may instruct workers and through which roles;

• staffing, substitution, and subcontracting;

• acceptance evidence and change control;

• REPSE number, authorized scope, validity, renewal, and notification duties;

• payroll, IMSS, INFONAVIT, tax, ICSOE, and SISUB evidence;

• worker-access, security, privacy, IP, and confidentiality controls;

• indemnities, joint-liability response, and audit rights;

• suspension and termination triggers; and

• transition, access removal, data return, and record retention.

The agreement must match daily conduct. Provider managers need to manage provider employees when the contract says the provider owns delivery. A governance call should not quietly become direct personnel administration.

The broader software outsourcing contract should align scope, acceptance, IP, security, pricing, and exit with the REPSE position.

Buyer liability makes ongoing evidence necessary

REPSE diligence continues after procurement.

Under Article 14 of the Federal Labor Law, the beneficiary can face joint liability when a contractor fails to meet obligations to workers used in the contracted service. Tax rules also condition treatment of specialized services on the legal and evidentiary requirements.

Article 1004-C adds a separate enforcement consequence. Prohibited personnel subcontracting or providing subcontracted services without the required registration can attract a fine of 2,000 to 50,000 UMA. Other liabilities may also arise. The same range applies to a person or company that benefits from subcontracting performed contrary to Articles 12 through 15. State the range in UMA in the control file rather than freezing it into an undated peso amount.

The buyer's file has four distinct components:

1. the Federal Labor Law contract and liability requirements;

2. the Federal Tax Code restrictions on prohibited personnel subcontracting;

3. Income Tax Law evidence, including relevant payroll CFDIs and proof of withholding, IMSS, and INFONAVIT payment; and

4. VAT verification, including the provider's applicable return and payment evidence for the relevant period.

A registration record shows status and scope. Payroll and filing records are needed to establish whether employees were paid, taxes and contributions were remitted, the service remained in scope, and the supporting evidence matches the invoiced period.

ICSOE and SISUB reporting obligations

REPSE, ICSOE, and SISUB serve different functions, so buyers need both the registration record and the applicable four-month filings.

ICSOE

IMSS uses ICSOE for information about specialized-service contracts and workers. Official guidance describes a four-month reporting cycle, generally within the first 17 days of January, May, and September. When the final day is not a business day, the date moves under the applicable rule.

For an in-scope arrangement, request filing evidence and reconcile:

• provider identity and employer registration;

• beneficiary identity;

• contract dates and service;

• worker information and covered period; and

• corrections or supplementary filings.

Do not turn a one-period filing extension into the general calendar. Confirm the current deadline for the reporting period.

SISUB

INFONAVIT's SISUB is the electronic channel for employers registered under the specialized-services regime to report contract, worker, and beneficiary information on a four-month basis.

The ordinary SISUB calendar is January through April reported from May 1 to 17, May through August reported from September 1 to 17, and September through December reported from January 1 to 17 of the following year. The deadline moves under the applicable rule when the final day is not a business day, so confirm the date for the actual reporting period.

Request the relevant receipt and submission files. Compare the provider, beneficiary, contract, workers, dates, and reported service with the deal documents and invoice population.

ICSOE and SISUB add reporting evidence to the buyer's control file; payroll records remain a separate requirement.

A practical REPSE evidence schedule

The required evidence changes with the stage of the engagement.

Assign an owner and deadline for each item. Evidence that arrives after the buyer has paid every invoice is a weak control.

How to verify a software provider in the REPSE register

Run the check against the legal entity, contracted work, and actual management model.

1. Identify the employing entity. Ask which Mexican legal entity employs every person who may perform the service. Search that entity rather than relying on the commercial brand.

2. Search the current public register. Use the legal name or RFC, save the result and check date, and review active and cancelled status information where available.

3. Compare the authorized description with the statement of work. Map the registered service to the deliverables, work locations, and people involved. Escalate ambiguous or generic descriptions to Mexican counsel.

4. Test the buyer's corporate purpose and activity. Use current corporate and tax records. Document whether the service sits outside them and why.

5. Map direction in practice. Name provider and buyer managers. Record who assigns work, controls hours and leave, supervises performance, approves replacement, and accepts delivery.

6. Collect the supporting evidence. Define the payroll, tax, IMSS, INFONAVIT, ICSOE, SISUB, and renewal records the buyer will receive, their cadence, and the consequence of failure.

REPSE red flags for software buyers

These signals justify escalation before access or payment.

• “All software is specialized” with no buyer-specific analysis.

• “Remote workers are outside REPSE” based only on location.

• A registration held by an entity that neither contracts nor employs the team.

• An authorized service description that does not match the work.

• A managed-project contract paired with direct buyer control of individuals.

• No approximate worker count or process for changes.

• Refusal to provide payroll, IMSS, INFONAVIT, tax, ICSOE, or SISUB evidence where applicable.

• Expired registration or renewal handled only after the buyer notices.

• Invoices that do not reconcile to the reported workforce.

• A promise that registration removes buyer joint liability.

Any one of these deserves a pause. Several together suggest the commercial model and legal model have diverged.

REPSE, IP, privacy, and security

REPSE addresses specialized-services registration. Handle software ownership separately, and apply Mexico data privacy law and software outsourcing security to the delivery systems and data:

• a rights chain from each developer through the employer and provider;

• foreground and background IP terms;

• open-source and third-party component controls;

• a data-role and purpose map under the current LFPDPPP;

• hosting, access, transfer, subprocessor, incident, retention, and deletion terms;

• least-privilege access and scoped security evidence; and

• repository, environment, credential, and exit control.

The recurring buyer questions turn on the same distinction: registration status and operating facts must agree.