When one rejected data batch should not hold up payment

A delivery plan can look reassuringly precise: one export now, another later, a price beside each. Yet the payment clause may make every invoice depend on approval of the final package. The owner has arranged the work in stages without arranging to be paid in stages.

Commercial lawyer Ilya Shilov, writing about business contracts governed by the law of England and Wales, puts the problem plainly: “If every payment depends on the final launch, dividing the work into milestones will not itself help.” His payment-terms article challenges the assumption that a staged schedule creates a separate right to invoice.

For a data license, put three things beside each other before agreeing to a split: the scope being accepted, the amount allocated to it, and the condition allowing that amount to be invoiced. A manifest can identify the files. A price schedule can assign an amount. The payment terms still have to connect those facts to an obligation.

An actual data contract makes that connection visible. In micro1's Data License Master Terms, updated November 12, 2026, section 3 allows invoicing after express or deemed acceptance; undisputed amounts follow a conforming invoice and the order form's payment period. An executed, referencing order form is required. Its conflicting terms prevail, and its effective-date version governs unless the parties adopt another in writing.

A positive technical message may therefore leave the commercial decision open. Before invoicing, check the required form of acceptance and who can give it, rather than relying on an upload confirmation.

The invoice also needs the correct parties. Identify who licensed the data and who owes the license price. If a broker has a separate fee arrangement, check that obligation separately. A commission calculation cannot establish that the buyer owes the owner an invoiceable amount, and an invoiceable amount does not establish that either party has received cash.

The useful question before signing is specific: can this identified collection be accepted and invoiced while that other collection remains unresolved? If the answer is yes, the scope, allocation and invoice clause should all support it. If the answer is no, decide whether that dependency is worth accepting before committing to the delivery work.

A good boundary survives the removal of the neighboring batch. Ask what the buyer could still accomplish with the remainder, using the purpose and coverage specified in the proposal. The answer needs to be more concrete than the files are readable.

Rightmark's note on what makes a complete game project gives a useful illustration. Source code can be present while a required map, asset, plugin license or engine version is missing. A folder full of code does not answer whether the proposed project can run. The relationship between the delivered materials can matter as much as each material's individual condition.

Apply that reasoning to the proposed acceptance unit. If a buyer needs linked records, removing one collection may remove the relationship it wanted. If it needs a defined population, removing the difficult cases may defeat the agreed coverage even though every remaining record passes a local check. The owner needs to explain the useful remainder in the terms the buyer chose, rather than substitute a different use after something fails.

Rights can cross the boundary too. Two technically separate collections may depend on the same source permission. Splitting them into different transfers cannot answer a question about whether that permission covers the proposed use. A credible proposal for independent acceptance identifies both the dependencies that stay inside each collection and those shared by the whole delivery.

Then test the price allocation. One tenth of the files is not necessarily one tenth of the bargain. The buyer may have offered one price for complete coverage, or for relationships across the archive. Removing a portion could leave an amount that neither side would have agreed for the remainder on its own.

A separate price is more persuasive when both sides can explain what it buys without referring to an unfinished component. That is why the commercial unit should be settled alongside the acceptance criteria. Trying to invent an allocation after rejection turns a quality discussion into a second negotiation over what the buyer was purchasing.

An owner can put the proposal in one sentence: this version provides this agreed use, at this price, even if that separate collection fails. The buyer should be able to test the sentence by naming the dependencies it thinks have been overlooked. A missing link, coverage commitment or common permission is a substantive objection. A preference for one invoice is a different objection, with an administrative cost to weigh.

This test does not require every useful collection to be licensed separately. It identifies where the parties have a reasonable basis for doing so. They can still choose a package because that is the better offer, or because its simpler review process is worth the additional payment dependency.

Consider an invented example. The owner and buyer are imaginary, and the collections, prices, permissions, contract terms and outcomes below are fictional. These are two alternative bargains considered before signing, not a buyer changing its requirements after delivery.

The owner has assembly manuals and maintenance records. Both are fixed at version 1. The manuals use canonical product identifiers. The maintenance records use local product codes and need an agreed mapping to those identifiers. The delivery is missing that mapping.

Assume the owner has the necessary authority and permissions for both proposed scopes, with no shared privacy, provenance, title or consent defect. All prices are invented fixed USD license amounts. There is no deposit, offset, package discount, tax adjustment, cross-default tying the collections together, or other unmet invoice condition. Preparation costs, intermediary fees and owner net proceeds are outside this calculation. Review does not grant training or other use rights; the governing license determines those permissions.

Proposal A buys two useful collections

The buyer wants the manuals for an assembly-instruction task and the maintenance records for a separate maintenance task. Its assembly work needs the complete manual for each included product, keyed to the agreed product identifier. It does not need a maintenance history to interpret those instructions. Under this proposal, the manuals can meet their purpose even if the maintenance collection is never accepted.

The parties agree $12,000 for manuals v1 and $8,000 for maintenance records v1. Each collection has its own acceptance decision. Each expressly accepted collection can be invoiced independently at its allocated price, identifying the accepted version and scope.

The authorized reviewer expressly accepts manuals v1 against their agreed criteria. The maintenance records fail their separate requirement because the product-code mapping is missing. The owner can therefore invoice $12,000 under these assumed terms. It cannot yet invoice the $8,000 maintenance component.

The mapping failure is still important. It prevents the buyer from using the maintenance records as specified. But it does not remove the product identifiers already present in the manuals or stop those manuals from supporting the separate assembly task. Holding that independent invoice would not follow the conditions assumed in Proposal A.

Proposal B buys the relationship between them

In the alternative bargain, the buyer wants paired examples: a maintenance record linked to the relevant assembly manual. Those relationships are the purpose of the acquisition. The parties agree a single $20,000 price and one acceptance decision for the joined collection. That price can be invoiced only after the complete collection is accepted; this proposal contains no partial-acceptance clause.

The same mapping is missing. The manuals still open, their product identifiers are present, and the words on each page are unchanged. Yet the buyer cannot associate the maintenance records with the correct manuals as the agreed task requires. The authorized reviewer records the joining failure, so the single invoice condition has not been met. The amount eligible to be invoiced under that condition is $0.

Offering the manuals alone would now propose a different purchase. Their usefulness for an assembly-only task does not fulfill the joined task this buyer specified. A revised scope and price might be worth discussing, but neither side can obtain that new bargain simply by assigning a percentage to the files that passed review.

The totals are equal: $12,000 plus $8,000 is $20,000. That choice isolates the effect of the agreed scope and trigger. It does not establish that two independent licenses have the same market value as a license for a linked collection.

Neither imaginary owner has received payment at this point. Proposal A establishes an amount that may be invoiced under its stated conditions. It does not establish a payment receipt, net owner earnings or an earned broker commission. Proposal B does not establish an overdue debt. Correction funding, refunds and actual payment dates remain outside this comparison; those questions need their own agreed terms.

The defect stayed the same. What changed was the job the buyer was buying and the condition the parties attached to its price. That is the distinction to resolve before a delivery fails, while both sides can still choose the bargain.

The strongest case against splitting acceptance is a buyer that needs the collection to work as a whole. Paying for several locally acceptable pieces could leave it financing an incomplete purchase and carrying the risk of assembling something useful from the remainder. Proposal B shows why a buyer can reasonably refuse that arrangement.

This concern appears in micro1's same published terms. Section 1.3 permits whole-data rejection when valid partial rejection makes the remainder no longer reasonably usable for the specified AI purposes or materially diminishes its value. Acceptance preserves warranty remedies, with separate limits for solely technical latent defects. Section 4.3 also preserves post-acceptance termination for a good-faith finding of material manifest inaccuracy or other material misrepresentation. These are provisions of that agreement, not a general rule for every license.

For the commercial decision, distinguish a missing component from a shared problem. In the invented example, absent mapping affects only the maintenance task in Proposal A. Change the assumption to a permission defect covering both collections, and the apparent separation offers no answer. The issue concerns whether the affected material can be licensed for the proposed uses at all. Passing the manuals' technical checks would not resolve it.

That is a reason to preserve the appropriate rights review and contractual response, even when invoices are separate. It is not a reason to treat every later complaint as cancellation of every earlier decision. Identify the affected scope, the obligation in question and what the governing terms actually allow. The response might concern correction, a changed scope or termination; choosing among them requires the agreement and the facts.

There is also a simpler case for one acceptance decision: the work of dividing the deal may exceed its benefit. Separate scope descriptions need to stay consistent. Someone must review each part, reconcile dependencies and maintain the allocations. A small, clearly specified delivery may be easier for both sides to manage as one package.

The owner has a commercial interest here too. If the buyer's offer depends on receiving a coherent collection, breaking it apart could sacrifice the very purchase the owner wants. A proposal for independent payment should explain why the parts retain their agreed value, rather than assume that smaller invoices always improve the deal.

One package wins when the intended use crosses the proposed boundary, the defect crosses it, or administering the boundary costs more than it solves. That choice should still leave a clear acceptance decision. Buying the whole collection does not require vague criteria or a new definition of success after delivery.

Before signing, ask both teams to walk through one failed component. Which identified scope could still satisfy its own acceptance and invoice conditions? If the answer is none, identify what the buyer would lose: required coverage, a relationship between records, permission to use them, or the package it actually priced.

Rightmark's data licensing agreement checklist puts scope, approvals and payment questions in the same review. Its payment row asks about the trigger, schedule and adjustments. Use that wider checklist for the full agreement, then record the particular decision that would apply to this delivery.

For the invented Proposal A, a concise decision record could read:

Scope accepted: Manuals v1, covering the specified products and assembly-instruction purpose. The authorized reviewer has expressly accepted that scope against its criteria.

Amount eligible for invoicing: $12,000, the agreed manuals allocation. The invoice condition expressly permits this accepted collection to be invoiced independently of the maintenance collection.

Scope still open: Maintenance records v1, allocated $8,000. The required product-code mapping is missing, so that collection has not met its acceptance condition.

Boundary checked: The missing maintenance mapping does not change the accepted manuals' separate use or permissions. A problem affecting rights to both collections would require review of the affected scope and the applicable terms.

Cash received: $0. The record identifies invoice eligibility only.

This fictional note connects a decision to its scope and amount. It is a coordination aid, not replacement contract language. In a real record, attach the actual acceptance evidence and point to the operative invoice clause. The person processing it should not have to reconstruct the bargain from an upload notification and a price spreadsheet.

Now test the exception. If the buyer required the missing mapping to join maintenance records with manuals, the note's independence statement would be false. The team should return to the package decision in Proposal B, rather than reuse Proposal A's $12,000 allocation. If a shared rights issue emerges, route that issue for the relevant review instead of assuming an earlier technical acceptance insulated the manuals.

Where the proposal remains unclear, ask for clarification or an agreed change. Where fixed terms make the whole delivery one acceptance unit, the owner must decide whether that offered risk is acceptable, whether a narrower scope is available, or whether to decline. An attractive total cannot answer that decision on its own.

The owner should be able to trace an invoice to useful scope it has satisfied. The buyer should be able to explain why any wider failure prevents that scope from delivering the agreed value. Defining both is what makes separate acceptance a serious commercial proposal.

If you are weighing a data license, bring the proposed collection and its acceptance questions to discuss the scope with Rightmark.