Contractor or employee: the process doc you write for your editors can answer it for you

On 15 June 2006 the International Labour Organization adopted a short document called the Employment Relationship Recommendation, 2006 (No. 198).

I read it on 16 October 2026, because I wanted one reference that sits above any single country's rulebook.

It is not a law you can be fined under. It is a list of what governments are encouraged to look at when they decide whether someone works for you or works with you. And it reads uncomfortably like a review of a small agency's process doc.

Step 1: the label is the weakest evidence you have

I pay editors across the VALORAE group, and in paying them on the agreed date I described that as a contractor payment cycle.

The word "contractor" in an agreement feels like the answer. It is closer to a claim.

Paragraph 9 of Recommendation No. 198 says the question should be guided primarily by the facts relating to the performance of work and the remuneration of the worker. It adds that this holds however the relationship is characterised in any contrary arrangement, contractual or otherwise.

So the heading on page one barely registers. What counts is how the work runs on a Tuesday.

Paragraph 13 then lists indicators. I grouped them into three buckets, because that is roughly how most tests I have read sort them: control of the work, the money, and the shape of the relationship.

Step 2: the complication sat in the SOP

Here is the part that catches people.

Everything I have recommended for quality points toward more control. In what breaks first when an agency grows I argued for a rejection log, earlier review and written defaults. Those are good habits. They are also, if you write them carelessly, a document describing how you direct someone's work.

The first indicator in paragraph 13 is work carried out according to the instructions and under the control of another party. An SOP is a set of instructions. That is the whole tension.

So reread yours as if you were the person deciding whether the editor is an employee.

Some lines will be fine. The deliverable spec. Caption safe area, hook placement, file naming, audio levels, the date it is due. Any contract for services has a spec.

Watch for the other kind. A line asking editors to be reachable during a fixed window. A line naming a required app when what you need is a required file format. Wording that tells a grown professional how to sequence their own afternoon.

None of that is malicious. It is what happens when you write a process doc the way you would brief yourself, and most of us brief ourselves in exactly that voice.

Step 3: control the output, not the hours

The same list names work carried out within specific working hours or at a workplace specified by the party requesting it, and work that requires the worker's availability.

Those two lines are what an SOP touches directly.

So the rewrite is boring. Every line in the doc should describe a property of the delivered file or a date. If a line describes the editor's behaviour on the way there, it has to justify itself or go.

"Deliver a 9:16 export with captions inside the safe area by the agreed date" is a spec.

"Work in this editor, between these hours, and send progress updates" is supervision.

The quality standard does not get weaker. It moves from the process to the acceptance test, which is where it belonged anyway, because you can check a file and you cannot check an afternoon.

Step 4: let the money behave like a business

The money indicators in paragraph 13 are specific. Periodic payment. Pay that is the worker's sole or principal source of income. Entitlements such as weekly rest and annual holidays. Travel paid by the party requesting the work. And absence of financial risk for the worker.

That last one is the cleanest test of the lot.

An employee is paid for time and cannot lose money on a job. A contractor can, because they choose how to spend their own time, tools and effort to hit a price.

That has a practical consequence for how you pay. A fixed amount per deliverable looks like buying a result. Pay for hours logged against your schedule looks like a wage. The total can be the same and still say different things about the relationship.

Tools sit on the same list: the provision of tools, materials and machinery by the party requesting the work. Editors who bring their own machine and their own software are running a small business. That is the shape you want, and most good editors already prefer it.

I should be honest about the limit here. I do not know where every editor I pay will sit under every regime they live in. Nobody running a small shop does. The aim is a relationship that reads clearly as two businesses, and advice when a specific case is unclear.

Step 5: do not own their calendar

The relationship indicators are the ones that creep.

Paragraph 13 lists integration of the worker in the organisation of the enterprise, work performed solely or mainly for the benefit of another person, work that must be done personally, and work of a particular duration with a certain continuity.

Editing is core to a video agency, so integration will never be perfectly clean. The others you can influence.

Do not forbid an editor from taking other clients. Do not schedule them like staff. Do not hand out titles that only make sense inside an org chart.

There is a commercial reason to want this too. An editor with other clients is less fragile, and a less fragile editor tends to leave on better terms. The same logic is behind volume deciding freelancer vs in-house in the first place, which is how VALORAE Media frames the choice for its clients: once the work fills a working week, every week, a hire may simply be the honest answer.

Sometimes the right fix is an employee.

If you find yourself writing an SOP that only works when someone is available on your hours, every day, for you alone, stop editing the SOP. You are describing a job. Hire for it properly.

Step 6: check where you both are

Recommendation No. 198 is guidance for governments. The test that binds you is whatever applies where you are, and where the editor is, and those can be two different places.

Tests differ by jurisdiction. Some authorities publish an online status checker. Some will give a formal ruling if you ask, slowly. Some lean on courts. And they change, sometimes in the middle of a year.

So the useful move is small. Find the official guidance of the tax and labour authority in each place that matters, read the questions it asks, and compare them with your SOP line by line.

The questions are the valuable part. They tell you what an authority thinks matters, in plain language, and they are usually free to read.

The short version

• Treat the word "contractor" in an agreement as a claim, not proof.
• Reread your SOP as the person checking whether you are an employer.
• Write every line about the delivered file or a date, never the hours.
• Pay per deliverable and let editors use their own kit.
• Never stop a contractor from taking other clients.
• If the work needs someone on your hours every day, hire an employee.
• Check the authority where you and the editor are, and get advice there.

I write operator notes like this at tgsidd.com.