When AI data buyers actually pay: the payment terms in a data offer

Most AI data buyers pay when they accept the data, or when someone further down the chain pays them, not when the holder signs. micro1 lets a holder invoice only after it has accepted the data in writing, and gives itself 30 business days after delivery to reject it, with silence counting as acceptance. Appen pays on acceptance rather than submission and Centific when the data is accepted. pre.dev pays within 15 days of receiving a buyer's cleared funds and warns that buyers commonly pay on 60-day terms, and Troveo has no fixed payout schedule at all. Grepped publishes two clocks on two of its own pages: within 7 days of the data passing review on one, within 30 days of each lab payment on the other.

Few buyers give a number of days. Of the ten buyers our main selling guide compares, 5 publish how soon a holder is paid, and the numbers that exist mostly count from the first call or the signature, not from delivery: Labelbox advertises under 21 days from first call to first wire, Mercor 2 to 4 weeks from the signed agreement, and Mode about three months from the first conversation. micro1 is the only buyer we read that publishes an acceptance window, and micro1 and pre.dev are the only ones that say when money already paid can be taken back ( micro1, pre.dev). The date that binds is the one written into the signed licence, which is why this guide ends with the questions that put it there.

This guide is for the founder, CFO or counsel of a company that holds a buyer's offer for its records or code, or is about to accept one, and needs to know when the money actually arrives and what can delay it or claw it back. It covers what starts each buyer's payment clock, the few day counts and where they start, acceptance windows, refunds after payment, the buyers whose own pages disagree, instalments and revenue shares, a list of questions to send back before signing, and how payment works in a sale AIData.Broker runs. Every buyer term below was re-read on its own page on 19 October 2026, and each links to the record that holds the buyer's words; the side-by-side comparison of the same buyers' other terms is in buyer programs compared, and the whole selling process is in how to sell company data to AI labs.

This guide is research from public sources, not legal, tax or investment advice.

Contents

1. At a glance: when each buyer pays
2. What starts the payment clock: four triggers
3. How long it takes, and where the count starts
4. Acceptance windows, and what silence means
5. Clawbacks and refunds after payment
6. Pages that contradict themselves
7. One payment or several: instalments, shares and relicences
8. What to ask before you accept an offer
9. How payment works in a sale we run
10. Questions people ask
11. What this means for you

1. At a glance: when each buyer pays

A buyer's offer usually leads with a price, and the price is the part a holder reads first. The payment terms sit lower down, and they decide something just as concrete: how long the company carries the cost of extraction, de-identification and its own staff time before any money arrives, and whether money that has arrived can be asked back. Two offers at the same price can differ by months on the day the cash lands, and one of them may leave the payment in the hands of a party the holder never signs with.

The table sets out, for every buyer on our board that takes company records or source code and whose pages we could read, the event that starts payment, the time it states, and whether it says paid money can come back. "Not published" means the buyer's pages say nothing on that point as read on 19 October 2026, not that the term does not exist: it may sit in an agreement the buyer sends only after the first call. The last column links the record that holds the buyer's own words.

Three things stand out once the rows sit side by side. The holder rarely controls the event that starts payment. Acceptance, review, approval and delivery confirmation are each the buyer's own act, and "after each lab payment" hands the trigger to a company the holder has no agreement with at all. Time is the least published term. Most rows give an event and no number, and where a number appears it often counts from the first call, which tells a holder how fast the buyer likes to move, not how long it may sit on delivered data. And refunds after payment are almost never described, which is not the same as their being absent: a licence can carry them even when the buyer's marketing pages do not, so the sections that follow treat each of these as a question to put in writing.

2. What starts the payment clock: four triggers

Every buyer above pays on one of four events, and the event matters more than any day count attached to it. A clock that starts at signature is under the holder's control: once both sides sign, the date is fixed. A clock that starts at delivery depends on how fast the holder, or whoever extracts and de-identifies the data, can finish the work. A clock that starts at acceptance depends on the buyer's judgment of the work. And a clock that starts when someone else pays the buyer depends on a third company's finances and its own payment terms.

The four triggers, from the one a holder controls least to the one it controls most, are payment after the end buyer pays, acceptance or passing review, contract milestones, and delivery or signing. A single offer can combine them: a payment at signing, a second on delivery, and a revenue share as each later licence is paid. When it does, each part has its own trigger and each deserves its own date.

Payment after the end buyer pays the intermediary

Several of the buyers on our board do not keep the data themselves: they license it onward to AI labs and pay the holder out of what the labs pay. pre.dev says so in the plainest words: a payout " depends on a buyer deal closing and pre.dev receiving the corresponding cleared funds", it pays within 15 days of receiving those funds, and its own agreement tells the holder to expect payment on the lab's cadence "rather than from the date a Buyer License is granted" ( pre.dev codebase agreement, section 13.6). Grepped's agreement page pays the holder's share within 30 days of each lab payment, with a statement. Troveo's licensor help pages say payments occur " only after your content has been licensed, the client has been invoiced, and payment has been received".

The same structure sits behind every buyer that pays per licence or as a share of what it earns: Magma pays a revenue share, paid as your data licenses, HUMXN and eeko pay per licence ( eeko adds a signed receipt of the records delivered), SuperAnnotate pays again on each relicense, Protege pays a share when developers license your data, and The General Data Company offers a share of what it earns from licensing as one of its two ways to pay. Under all of these, the holder carries the end buyer's credit risk: if the lab pays late, the holder waits; if it never pays, the holder may never be paid. Grepped is the one that says a holder can ask to see the lab's payment records, and that right is worth asking every buyer of this kind for.

Acceptance or passing review

The most common trigger among buyers that keep the data is acceptance. micro1's licence terms let the holder invoice only after micro1 has given written notice that the Data has been accepted, or after the data is deemed accepted because the rejection window passed. Appen's terms are agreed in writing before extraction and payment is on acceptance rather than submission; Centific's page says payment is made when the data is accepted; Nyne pays once your dataset is delivered and accepted. Polyshares approves the record first and then pays net 30 to 60, and Grepped's business page starts its clock when the data passes review.

Acceptance is a reasonable thing for a buyer to want: it is paying for data it has not yet seen in full, and review is how it finds duplicates, gaps and personal data that should have been removed. What turns acceptance into a risk for the holder is an open end. Of these buyers, only micro1 publishes how long its review may last; Appen, Centific and Nyne say nothing on their pages about a window, and none of the pages says what happens if the buyer neither accepts nor rejects. Section 4 covers what to ask. The principle is simple: an acceptance trigger needs a deadline, criteria fixed in advance, and a rule for silence, or the payment date is whatever the buyer's review queue makes it.

Contract milestones

A third group sets payment in stages tied to steps in the agreement. Handshake AI says payment terms are tied to defined delivery milestones, and that the holder receives written details on the payment amounts, milestones, and schedule before any data is transferred. The General Data Company's page says payment follows the agreed milestones. Corpus Bridge, a broker, gives the clearest example: the buyer pays half on signature and half on delivery. Mode leaves the schedule to the written agreement, set before export.

Milestones are only as good as their definitions. A milestone the holder completes and can prove (a signature, a delivery with a signed receipt) protects it; a milestone the buyer declares (its quality review passed, its model trained) does not. The General Data Company's own terms say it prepares, anonymises and checks the data before payment follows, so its milestones depend partly on its own work. Tie every milestone to a date or to an act the holder can evidence, and write down what happens to the money for a completed milestone if a later one fails.

Delivery or signing

The smallest group pays on an event the holder can see. Mercor pays by wire upon delivery of the anonymized dataset to the buyer, and says it covers extraction and anonymisation with no deductions from the payment. Note who the buyer is in that sentence: Mercor's own buyer, the lab. The trigger is delivery onward, after Mercor's processing, not delivery from the holder to Mercor. SuperAnnotate pays on delivery and again on each relicence; Collinear pays after it confirms delivery is complete. Labelbox is the one buyer we read that pays anything at signing: an upfront licensing fee at signing plus a revenue share on downstream use.

Delivery-based payment is also the shape of the largest disclosed sale of company records. In the Spirit Airlines bankruptcy, Google's agreement to buy de-identified records for $10 million provides that the buyer shall deliver the Purchase Price at the same time as the data is delivered, and delivery requires an independent agent's certificate that the data is de-identified. A delivery trigger therefore moves the question to what counts as delivery: in a record sale that usually includes de-identification to an agreed standard, so the standard, the certifier and a deadline for the de-identification work belong in the licence. Our guide to data licensing agreements sets out the clauses.

3. How long it takes, and where the count starts

A stated number of days is only meaningful with its starting point, and the published numbers start in very different places. Labelbox's under 21 days counts from the first call, so it includes scoping, the agreement and extraction. Mode's about three months runs from the first conversation through payment. Mercor's 2 to 4 weeks runs from the signed agreement and depends, in its own words, on extraction and processing time. Ooak's headline 2 to 4 weeks stands beside its largest price with no starting point at all.

The counts that start at the moment that matters to a holder's cash, the delivery of its data, are rarer still. Polyshares states net 30 to 60, but counted from its own approval, not from delivery. Grepped's 7 days starts at review and its 30 days at each lab payment. pre.dev's 15 days starts only after the lab pays it, and the lab, it says, commonly pays on 60-day terms. Centific's six to ten weeks counts to the first accepted contribution, which is a milestone, not a payment.

Read together, the rows show why a holder should translate every stated time into one question: how many days after my data is delivered will the money be in my bank? A count from the first call is a sales promise, a description of how quickly the buyer usually moves when nothing goes wrong. A count from the signature is better, but it still folds in the extraction and de-identification work, which slips whenever the holder's systems are harder to export than expected. Only a count from delivery, with a fixed end, tells a CFO when to expect cash. Where a buyer's trigger is acceptance, the honest answer is the acceptance window plus the payment period: under micro1's terms, 30 business days of review, which is longer than a calendar month once weekends are counted, then the period the order form sets after a conforming invoice. Where the trigger is the lab's payment, the answer is the lab's own terms plus the intermediary's, and pre.dev tells holders to expect that cadence openly.

The published times are also best cases. Mercor's figure is what "typically occurs"; Troveo's licensor pages state plainly that there is no fixed payout schedule. Our own reading of the market, in the selling guide's process section, is that most of the time in a sale passes before signature, in valuation, the rights file and the buyer's review, and that the payment terms decide how much of the remaining wait is the holder's risk. The negotiation levers record the pattern buyers have accepted: days to weeks, with a signature tranche.

4. Acceptance windows, and what silence means

micro1 is the only buyer on our board that publishes how acceptance works, and its terms are worth reading in full because they show every moving part. After delivery, micro1 has thirty (30) business days to reject the data by written notice "identifying the affected Data and describing the deficiency in reasonable detail"; if it gives no timely notice, the data is deemed accepted. Only then may the holder invoice, and micro1 pays undisputed amounts within the period stated in the order form, counted from receipt of a conforming invoice; for data it validly rejects, it owes nothing. Section 1.3 of those terms, which sets the rejection window, also says micro1 owes nothing for any part of the data it validly rejects.

Three features of that clause protect the holder, and a holder should look for the same three in any acceptance-based offer. The window has an end, counted in business days from delivery. A rejection must be written and must identify what is wrong, which gives the holder something to fix rather than a bare refusal. And silence counts as acceptance, so the buyer cannot hold the payment simply by not answering. The cost to the holder is the length: the data is in the buyer's hands for the whole window with nothing paid, which is why the question our offer check sends back to micro1 is whether the window can be shorter.

Appen, Centific and Nyne also pay on acceptance, and none of their pages says how long acceptance may take or what silence means. Appen's terms are agreed in writing before extraction begins, and Centific's page uses almost the same words, so the window is a term to settle in that written agreement before any extraction starts. Nyne's own offer comparison treats payment conditions as part of what makes two offers comparable, which is a reminder that a buyer that wants to beat a rival offer should be asked to match its payment terms as well as its price. The questions to put to any buyer that pays on acceptance are these:

1. How many business days after delivery does the review last? A number, written in the licence, counted from a delivery the holder can evidence.
2. What happens if the buyer says nothing? Deemed acceptance at the end of the window, as micro1's terms provide.
3. What are the acceptance criteria? Objective tests agreed before extraction (format, counts, de-identification standard), not the buyer's satisfaction.
4. Can part of the data be accepted? Payment for the accepted part should not wait for a dispute over the rest.
5. Is there a right to cure? A rejection should give the holder a fixed time to correct or replace the affected data before the buyer may refuse it.

Each of these narrows the gap between delivery and payment without asking the buyer to give up its right to review. A buyer that resists every one of them is telling the holder that it wants to hold delivered data, unpaid, for as long as it likes. The licence terms page collects the published acceptance and delivery clauses across buyers, and the market position on acceptance is part of the licence term for delivery format, refresh and performance: specify format, schedule and acceptance, and avoid obligations the holder cannot meet.

5. Clawbacks and refunds after payment

Payment is not always the end of the money question. Two buyers on our board publish terms under which money already paid can come back, and both deserve a careful read before signing. Most buyers publish nothing on the point, which leaves it to the licence they send after the first call; a holder should assume such a clause may be there and ask.

micro1's terms carry two. The broader one follows from the data manifest, the holder's own description of what it delivers. If micro1 determines in good faith that the manifest was materially inaccurate when provided, it may terminate, nothing is payable, the holder will refund any amounts already paid, and the right survives Licensee’s acceptance or deemed acceptance of the Data (section 4.3). No time limit is stated. The narrower one covers latent defects in technical quality and material non-conformity with the manifest: micro1 must raise such a claim within 60 days after acceptance, and the holder then chooses whether to correct or replace the data or refund the proportionate amount paid for it. The practical lesson from both is the same: the manifest is a financial document. Counts that are inflated by duplicates, or a description that overstates what the data covers, can reverse a paid sale long after the money arrived.

pre.dev's codebase agreement passes the lab's refunds through to the holder, after a wait that starts before any deal exists: a lab usually reviews a codebase for 4 to 12 weeks first, and pre.dev may hold payment until the holder's tax form and payout account are on file. If funds a buyer paid are later refunded, charged back, credited or clawed back, pre.dev may deduct proportionate amounts from future payments to the holder or recover them from it directly, again with no time limit stated. Because pre.dev pays only out of what labs pay it, this keeps it whole whatever happens upstream, and leaves the holder exposed to disputes it is not party to.

Outside company data, the same pattern appears in consumer programmes. Kled's terms require a contributor whose consent is withdrawn to immediately refund what it was paid for that content, and HUD's DataVendor, a code exchange, says that while it is in beta its payouts sit behind operational switches that DataVendor can pause temporarily. Neither is a company-records buyer, but both show that a payment can be conditional long after it is made.

When a licence contains a refund right, four limits make it fair to both sides:

• A time limit. The right should end at acceptance, or at a fixed date after it, so that a paid sale becomes final.
• A proportionate amount. A refund should cover the part of the data that was defective or misdescribed, not the whole price.
• Repair first. The holder should have the right to correct or replace data before any refund, as micro1's latent defect clause already provides.
• No set-off across sales. A dispute over one licence should not be deducted from payments under another.

None of these asks the buyer to accept a bad delivery. They ask it to raise problems promptly, to measure the remedy against the problem, and to let the holder fix what can be fixed. A buyer that pays on acceptance and also keeps an unlimited refund right is asking for two kinds of protection for the same risk, and the holder can fairly ask it to choose. In a sale we run, the mandate already mirrors this on our side: if a holder repays money to a buyer, our fee on that amount is credited or refunded, as section 9 explains.

6. Pages that contradict themselves

Four buyers on our board publish payment terms that disagree with themselves, on the same day, on their own pages. None of this is evidence of bad faith: marketing pages are written at different times by different people, and a page that sets out an agreement is often more careful than a landing page. But it does mean that a holder cannot rely on any one page for the payment date, and the contradictions show exactly which questions to ask.

Grepped. Its business page says the holder is paid "Within 7 days of your data passing review", and that most companies go from the form to payment in a few weeks. Its data page, which summarises its data supply agreement, says the holder is paid its share "within 30 days of each lab payment". These are not two speeds of the same clock: one starts at Grepped's own review, the other at a lab's payment, which may come long after review. The question to send back is which of the two its agreement uses, and what happens if the lab pays late.

Mode. Its site says Mode "generally expects about three months from the first conversation through payment", with the amount and the payment schedule set in the written agreement before export. Its paid launch release of 13 October 2026 said payment was expected within about 60 days after the final offer is accepted, and described a short letter of intent that the site does not mention. The two counts start at different points, but the release is the shorter promise, and only the written agreement binds.

Mercor. Its FAQ says payment is issued by wire "upon delivery of the anonymized dataset to the buyer". Step four of the process on the same page reads "Get paid as soon as processing is complete". Processing comes before delivery to the lab, so one wording ties payment to Mercor's own work and the other to the lab receiving the data. The difference is small in a smooth sale and large in a slow one.

Polyshares. Its FAQ says net 30 to 60 "once the data is approved, shared, and anonymized", and its process step says "approved, anonymized, and delivered". "Shared" and "delivered" may mean the same thing to Polyshares, but a licence should use one defined word, because the payment period runs from it.

How to pin the wording down

The signed licence decides, and in most written licences a clause says the signed document replaces everything said before it, so a promise on a web page that is not in the licence may not bind the buyer at all. Pinning the payment date down therefore means writing it into the licence in four parts: the trigger (one event, defined in one word), the period (a number of days), the starting point (the trigger itself, evidenced by something the holder can show, such as a delivery receipt), and the consequence of delay (interest, or a right to suspend delivery of later parts).

Where a buyer's pages disagree, ask it in writing which wording its licence uses, and keep a dated copy of the page you relied on. We date every reading of a buyer's page for this reason: the record behind each link in this guide shows the day it was read and the buyer's exact words, so a holder can show a buyer what its own page said. The buyer board carries each buyer's current terms, and the offer check lists, for a buyer whose offer you hold, the clauses to read first and the questions to send back.

7. One payment or several: instalments, shares and relicences

The timing question changes shape when a sale pays more than once. Turing promises "One payment. No retainer, no recurring commitment.", which is easy to plan around but means the holder is paid once whatever Turing does with the record afterwards. micro1's licence grants a worldwide, royalty-free, fully paid-up, nonexclusive, irrevocable, perpetual license, so its single payment also covers every future use; in our reading it should be priced as a sale, not as a licence that pays again. At the other end, Troveo shares in the revenue on every sale, Magma pays as the data licenses, and SuperAnnotate pays again on each relicence: income that can continue for years, but whose timing depends entirely on the intermediary's next sale.

Between these sit the mixed structures. Labelbox pays an upfront fee at signing plus a revenue share on downstream use. Centific says most companies it works with move to a quarterly refresh after the first payment, which turns a one-time sale into a recurring licence. The General Data Company offers either a one-off price or a share of what it earns. Corpus Bridge's example of half at signature and half on delivery is the simplest instalment structure, and in our reading a structure worth asking every buyer for.

The evidence from disclosed licences shows that front-loading is normal even on long contracts. Getty Images recognised about $40 million of two multi-year licences worth $65 million in the quarter they were signed, and Wiley realised $17 million of a $21 million content-rights project in its first quarter. Where a licence pays partly on usage, the market's answer is a floor: OpenAI pays Dotdash Meredith a minimum of around $16 million per year with a variable part on top, and most of its publisher licences are reported to have fixed and variable components. The market position on price structure is to anchor on a fixed minimum plus refresh or usage fees.

For a holder, every form of later payment raises the same three questions:

• What starts each part? Each instalment, milestone or share payment needs its own trigger and its own period, written down.
• How is it reported? A revenue share is only as good as the statement behind it: who reports each sale, how often, and with what detail.
• Can the holder check it? A right to see the end buyer's payment records, as Grepped offers, or an audit right over the intermediary's licensing income.

A share of future sales also carries a risk that a single payment does not: the intermediary's own survival. If it stops trading, the stream stops with it, and the data it already licensed stays licensed. A guaranteed minimum, a payment at signing, or a cap on how long the intermediary may hold the right to relicense all reduce that risk. Our guide to how much company data is worth covers how these structures change the price, and the lever on non-exclusive data records that non-exclusive data can be sold again, which is the case for keeping relicensing in the holder's own hands.

8. What to ask before you accept an offer

An offer that states a price and leaves payment to "the agreement" is not yet a complete offer. The questions below turn the payment terms into something a CFO can put in a cash forecast, and they cost nothing to ask: a buyer that intends to pay promptly can answer them in one email. SimpleClosure's advice to founders weighing large offers is the same in one line: the agreement should state the actual price, what must happen before payment is due, and when it will arrive.

Send the questions before the extraction work starts, while the holder still has the most leverage, and ask for the answers in the licence, not in a covering email. Where a buyer has a published page that says something different from its draft licence, cite the page back to it and ask which wording it will sign.

1. What single event starts payment: signature, delivery, acceptance, or another company paying you?
2. How many days after that event is payment due, and is that number in the licence?
3. If payment waits on acceptance, how long is the review, what are the written criteria, and does silence count as acceptance?
4. If payment waits on a lab paying you, what happens if the lab pays late or never pays, and may we see the lab's payment records?
5. Will any part be paid at signature? Half at signature and half on delivery is a published example.
6. Is the payment one sum, instalments, or a share of later sales? For each part: its trigger, its period and how it is reported.
7. Can any payment be taken back after it is made, on what grounds, for how long, and in what proportion?
8. Who does the extraction and de-identification, and does payment wait for it? If it waits, what is the deadline for that work?
9. What does the buyer need from us before it pays: tax forms, bank details, an invoice in a set form?
10. In what currency, by what method, and who bears the bank and conversion charges?
11. Are any amounts deducted from the price, such as processing costs, an exchange's share, or a withdrawal fee?
12. What happens to the payment date if the buyer is acquired, or stops buying data?

Questions 4, 7 and 11 are the ones holders most often skip, and they are the ones with the largest effect on what actually arrives. HUD's DataVendor keeps 20% of vendor earnings, taken only when earnings are withdrawn, and the lever on comparing offers records that two exchanges for code state their prices on opposite bases, one gross and one net. Mercor, by contrast, says it takes no deductions from the payment, and Appen that it covers extraction, anonymisation and transfer, so there are no costs to you. Question 9 is the quiet delay: pre.dev's agreement lets it withhold payment until the holder's tax documents and bank details are on file, without that being a breach ( pre.dev codebase agreement, section 13.7), and micro1's prices are exclusive of any applicable sales, use, or value-added tax, which the holder states separately on its invoice where required. The free offer check runs most of these against the buyer whose offer you hold and shows the clauses that buyer publishes on each.

9. How payment works in a sale we run

AIData.Broker acts as the holder's agent in the sale: the holder itself licenses or sells its data to the buyer, and we do not take ownership of it. That shapes how the money moves. The holder, or a provider it chooses, delivers the data to the buyer, and the buyer pays the holder directly, not through us: under the mandate we cannot receive the holder's payment. The holder alone decides whether to sell, to which buyer and on what terms, and the mandate lists payment timing among those terms by name. We run sales only for holders based in the United States, the United Kingdom and Canada.

Payment terms are part of every offer we pass on. Under the mandate, every offer, indication of interest and counter-proposal reaches the holder in writing with its full terms as the buyer stated them, what the holder would keep after our fee, and anything that buyer pays whoever introduces a holder. Because every buyer that fits hears of the data at the same time and answers by one deadline, payment terms can be compared across offers the way prices are: an offer that pays half at signing can be weighed against a higher one that pays only after a lab pays its intermediary. When the holder asks, we advise on the licence and help negotiate it, starting from the questions in section 8. The licence remains the holder's agreement, and the holder takes its own legal advice on it.

Our fee follows the holder's money, not the buyer's signature. It is a success fee on what the holder is actually paid, band by band: 15% of the first $250,000, 10% from $250,000 to $1 million, and 6% above $1 million. Four clauses of the mandate tie it to payment:

• No fee on money not received. The fee is payable only out of money actually received; no fee is due on money a buyer owes but has not paid, and we invoice the fee on each payment only after the holder has received it.
• Every form of payment counts, when it arrives. The mandate's Gross Proceeds include upfront payments, instalments, milestone payments, royalties and renewals, so a sale paid in parts is invoiced in parts.
• A reversed payment reverses the fee. If the holder repays money to a buyer, or a payment is recovered from it (the mandate's own examples include a buyer rejecting the data within an agreed acceptance period), the fee on that amount is credited against the next invoice or refunded.
• The tail follows the money too. A sale to a buyer we introduced, made within 12 months after the mandate ends and listed in writing, carries the fee on all money received under it, whenever received.

On a $300,000 sale our fee is $42,500, whichever buyer wins; if that buyer pays half at signing and half on acceptance, the fee is invoiced in two parts, each after the payment it is charged on has reached the holder, and counted band by band over the life of the sale. In a sale we run no buyer pays us: we decline any introduction fee a buyer offers, tell the holder the amount and ask the buyer to put it into the holder's price instead. A buyer pays us only if the holder chooses to apply to it through its own referral programme, and the holder sees that amount in writing before choosing. So in a sale we run our fee arrives only after the holder's money does, and our interest in the payment terms is the holder's. The mandate is exclusive for 2 months, and the full terms are on the pricing page and in how it works.

Questions people ask

When do AI data buyers pay for company data? Usually on acceptance of the delivered data, or after the end buyer pays the company you sold to, rarely at signing. micro1, Appen and Centific pay on acceptance ( micro1, Appen, Centific); pre.dev and Grepped's agreement page pay after a lab pays them ( pre.dev, Grepped); Labelbox pays an upfront fee at signing.

How long after delivery will I be paid? Most buyers do not say. The published times mostly count from the first call or the signature: under 21 days from first call at Labelbox, typically 2 to 4 weeks from signing at Mercor, about three months from the first conversation at Mode. Ask for a number of days counted from delivery and put it in the licence.

What does net 30 to 60 mean in a data offer? Payment is due between those two numbers of days after a stated event. At Polyshares the event is its own approval and the anonymisation and delivery of the data ( net 30 to 60), not your signature, so the clock starts only after its review.

Can a buyer take its money back after paying? Under some terms, yes. micro1 can require a refund of everything paid if the data manifest was materially inaccurate, even after acceptance, and pre.dev may deduct proportionate amounts from later payouts if a lab's payment is refunded or clawed back. Ask for a time limit and a proportionate amount.

What happens if the buyer never answers after delivery? Under micro1's terms the data is deemed accepted once the rejection window passes without written notice. Appen, Centific and Nyne publish no window and no rule for silence, so write one into the licence.

Do I get paid if the lab never pays the intermediary? Under terms like pre.dev's, Grepped's agreement page and Troveo's, payment depends on the lab paying first ( Troveo), so a lab that never pays may mean a holder that is never paid. Ask what happens in that case and for a date by which you are paid regardless.

Is a payment at signing normal? It is published by few buyers: Labelbox pays an upfront fee at signing, and Corpus Bridge's example is half on signature and half on delivery. Disclosed multi-year licences show buyers accept front-loading: Getty recognised about $40 million of $65 million in the quarter its licences were signed.

Do I need tax forms before a US buyer pays me? Usually. A holder outside the US that wants a treaty rate gives the buyer a Form W-8BEN-E before the payment is made, or the buyer withholds 30 percent; a US holder gives a W-9, and Troveo's help pages warn that a missing one can lead to backup withholding. Our guide to US withholding tax on data licence payments covers the forms and rates.

What this means for you

The payment terms in a data offer are as negotiable as the price, and buyers expect to be asked about them. Before you accept an offer:

1. Find the trigger. Read the offer and the buyer's licence for the one event that starts payment, and check it against the buyer's own pages in the table above.
2. Get a number of days from delivery. Translate any count from the first call or the signature into days after your data is delivered, and put that number in the licence.
3. Close the acceptance window. If payment waits on acceptance, fix the review period in business days, the written criteria, and deemed acceptance on silence.
4. Ask for part at signing. Half at signature and half on delivery is a published structure; a payment at signing also shows the buyer has the money.
5. Limit what can come back. A refund right should end at acceptance or a fixed date after it, cover only the affected part, and let you repair first.
6. Know who pays whom. If an intermediary pays you only after a lab pays it, ask for the lab's payment records and a date by which you are paid regardless.
7. Make the manifest exact. Under terms like micro1's, an inflated count can reverse a paid sale, so count net of duplicates.
8. Have the paperwork ready. Tax forms, bank details and a correct invoice are the delays that are entirely in your hands.

Know what the data is worth before you weigh how fast it pays: the valuation prices it against public sales and offers, binds no one and needs no upload. If you already hold an offer, the offer check places its amount against the market and lists that buyer's clauses on payment and the rest. The buyer board carries each buyer's current terms, someone offered to buy your company's data explains how to read an unsolicited offer, and selling directly or through a broker compares the two routes on what you keep. The rest of the journey is in how to sell company data to AI labs, the clauses in what a data licensing agreement contains, code sales in selling your codebase to AI companies, and holders abroad in buyers that accept holders outside the US.

This guide is research from public sources, not legal, tax or investment advice.