Subscription process: reviewing before you commit

Checking transactions and marking them ready — the gate every later stage depends on, and the two checks worth slowing down for.

Overview

Transactions arrive in a process as Draft. Marking one Ready is a deliberate act, and it is the gate everything downstream depends on: documents, payments and signature all draw on transaction data. Until transactions are ready, the payments table will tell you so plainly — "No transactions are ready to be processed yet."

Readiness is the deal team asserting this transaction is correct. An error caught here costs a minute; the same error caught after documents have been generated costs a rebuild.

What you'll learn

What the transactions table shows you
The two checks that carry real consequence
How to work through a large round
What becomes available once transactions are ready

Steps

From the project Dashboard, open the process under Active Operations. On the Subscription Dashboard, open Transactions Setup.
Review each transaction against your source terms — the file you imported, or the terms you were given.
Correct anything wrong while it is still Draft.
Set each correct transaction's status to Ready.
Repeat until every transaction is Ready.
The other stages now have data to work with — documents (A8.6) and payments (A8.13) become available.

What to check

The table shows, per transaction: Movement Type, Company, Issuer / Seller, Beneficiary / Buyer, Security Type and Par Value, alongside the amount and status.

Movement type — issue, transfer, contribution, free shares. The type determines which template applies and how the cap table moves.
Company — on a subscription across several ManCos, the right person in the wrong company is plausible and expensive.
The two parties — seller and buyer the right way round.
Security type — ordinary or preferred, and which class.
Quantity and par value — the numbers that will reach the cap table.

Two of those are worth slowing down for. Party direction, because reversed, the cap table moves the wrong way and nothing looks odd. And company assignment on a subscription across several ManCos — a participant subscribing across three ManCos should appear once per ManCo, not three times in one.

On a large round, filter rather than scroll: you can narrow to Reserve, Issues or Deferred only.

What good looks like

Every transaction reads Ready, and each has been checked by a person against the terms — not merely imported and assumed. The payments and documents stages now show work to do rather than an empty table.

Common problems

"No transactions have been found or added yet." Nothing has been created. On the bulk path this suggests the import did not post; on the manual path, transactions are configured here and you have not added them yet.

A transaction is wrong and already Ready. Correct it before documents are generated. Once a document exists that was generated from wrong data, you have two problems rather than one (A8.6).

Buyer and seller reversed. Easy to do in an imported file and consequential. This is the single check most worth slowing down for.

The wrong company on a subscription across several ManCos. Filter by company and read each group.

A8.4 — Adding subscribers in bulk · where imported transactions come from
A8.6 — Subscription process: generating and reviewing documents · what readiness unlocks
A8.13 — Subscription process: payments · the other stage that waits on this
A6.4 — Share transfer · why party direction matters so much