Share transfer

Overview

This records a transfer that has already happened. As with an issuance, you are bringing the record up to date with something the paperwork already evidences.

A transfer you are about to make is run as a subscription process (A8.1) rather than here.

A transfer records a change of share ownership between parties. Existing securities move from one holder to another. Nothing is created, and share capital does not change — which is the whole distinction from an issuance.

That has a practical consequence when reading a cap table afterwards: an issuance dilutes everyone not participating; a transfer dilutes nobody. Total shares are unchanged.

The flow is the same document-led one as an issuance, so this lesson covers what is different about a transfer.

What you'll learn

• What separates a transfer from an issuance

• The one check that matters most on this decision type

• What else to verify in the extracted transactions

• Why a recorded transfer reads the same as one produced by a subscription process

Before you start

You need the legal documents evidencing the transfer. On a French transfer the instrument is usually an ordre de mouvement.

Steps

1. From the company navigation, open Timeline. It lists the company's events.

2. Select Record past event. Give the event an Event Label, then under Choose Decisions pick Securities Transfer.

3. Upload the legal documents. Analysis will not start without at least one.

4. Analyse. The platform extracts the transfer transactions.

5. Read the result — all imported, partially imported with an error report, or a failure.

6. Check the extracted transactions against the documents, and correct in the decision. Open a transaction and click the figure you want to change. A transfer carries a reserve on both sides — what the giver parts with and what the receiver takes in — and they move with the total, so correcting one figure keeps the other two consistent rather than leaving them to be fixed separately.

Check the direction first

A transfer has a transferor and a transferee. Reversed, your cap table is wrong in both directions at once — the transferor gains what the transferee should have received, and vice versa.

This is uniquely nasty because nothing looks odd. Both parties are real, both hold shares, and the totals still balance. There is no arithmetic signal that anything is wrong.

So read the two names against the document before accepting the extraction. It is the single most consequential check on this decision type.

Then check the rest

**Both parties exist as shareholders — but check how the transaction got here. Where the analysis extracted it from your documents, a party the company did not have is created as part of the extraction**, so a name you do not recognise may be new rather than wrong. Where you are entering the transaction by hand, both sides have to exist already or it cannot resolve.

Either way the check is the same, and it is worth doing: a shareholder created by extraction is a shareholder created from a document reading, so confirm it is the person you think it is before accepting the movement.

The quantity leaves and arrives. Shares out of one holder equal shares into the other. An asymmetry means one side was misread.

Security type. Ordinary and preferred are different things. Moving preferred when the document says ordinary moves the wrong economics, even where the count is right.

How it reads afterwards

A transfer recorded this way looks the same in the registry as one produced by closing a subscription: the movement, with its order of movement attached.

That is the intent — how a movement was recorded should not change how it reads.

Other transfers detected

The transfer decision carries the same section as an issuance, named Other Transfers Detected — movements the analysis found in your documents that belong to other companies. A6.3 explains what to do with them; the handling is identical.

Common problems

Direction reversed. The most likely error and the most consequential. Read the parties against the document.

A party is not a shareholder of this company. Add them, then re-analyse or correct the transaction.

Share capital changed after a transfer. It should not have. Check whether an issuance was mixed in.

The counts do not balance. Shares leaving must equal shares arriving. An asymmetry is an extraction error.

Related

• A6.3 — Share issuance · the same flow, and the contrast

• A5.2 — Share classes · why the security type matters

• A5.7 — The registry: tracing a transaction to its signed document · where the movement ends up

• A5.6 — Reconciling and correcting the record · fixing a reversed direction