Billing automation from the signed contract: deposits, milestones and recurring payments

Billing automation is software doing the parts of getting paid that people used to do by hand: creating the invoice, sending it, charging the card or debiting the account on schedule, chasing what's late and matching what arrived. Most tools start that chain at the invoice. This guide starts it one step earlier, at the signed contract, because that's where the amount, the dates and the client's permission to be charged get agreed in the first place.

Two terms get mixed up here. Automated invoicing usually means the sales side: invoices go out without anyone typing them. Invoice automation is often used for the opposite job, accounts payable, where software reads the supplier invoices you receive and routes them for approval. Both count as billing automation in the loose sense. Only the first one gets you paid.

Most explainers skip a step. An invoice is only as right as the terms it copies. If the price, the deposit or the billing date lives in an email thread and someone keys the invoice in from memory, automating the sending step just sends mistakes faster. Tie billing to the signed contract instead and the invoice inherits terms both sides have already accepted.

That's the idea behind contract-linked payments: the payment terms ride inside the agreement, and the signature is the trigger. It isn't the only way to set up billing automation, and the sections below cover the alternatives too, but it's the version where nothing has to be retyped.

Late payment is ordinary, not exceptional. Atradius's 2026 survey of US companies puts late payments at an average 22% of B2B receivables, with 1% to 2% of invoices lost as bad debt. About three in five US suppliers give business customers 30 days to pay.

Some of that is the client. A fair share is the gap between "signed" and "invoiced": the contract closes on a Tuesday, the invoice goes out the following week, and the 30-day clock starts late. Billing automation that begins at the signature closes that gap. It won't fix a client who simply doesn't pay.

Every model below can be automated, but only if the contract says enough for software to act on. A vague "half upfront, rest on completion" works between friends. It doesn't work for a system that needs the amount, the trigger and the date.

New York's freelance law makes a handy checklist even if you've never billed a New Yorker. General Business Law § 1412 requires a written freelance contract to state the rate and method of compensation and the date the client must pay, or how that date gets set. If your contract answers those questions, billing can run from it.

If you automate one thing, make it the deposit. It's a single charge, the trigger can't be argued with (the client signed), and it changes behaviour on both sides. Clients who've paid 30% are slower to disappear. You're slower to start work for clients who haven't paid anything.

Write the deposit as a number, not a mood. State the amount or percentage, what it's credited against, and whether any of it comes back if the client cancels. Some businesses send a proforma before the work starts so the client's finance team has a document to pay against. With payment at signing, the signed contract and the charge do that job together.

For large deposits from new clients, it's worth knowing who's actually signing. An optional ID check before the signature removes the "that wasn't me" argument later. Honestly, most small jobs don't need it.

Fair warning: payment at signing works best when the client is a person or a small company with a card. Larger buyers often need a purchase order and their own payment run, and they'll ask you to turn the deposit into an invoice with terms. Keep that version of the contract ready.

Milestone billing splits a project price into payments tied to deliverables: design approved, build delivered, launch done. It's the fairest model for work that runs over several months and the hardest to automate, because the trigger isn't a date. It's someone saying "yes, that's done."

Make acceptance a rule, not a feeling

The contract should say what counts as acceptance. Common versions are a written approval, a signature on a delivery note, or silence for a fixed number of days after delivery. Pick one. Without it, milestone payments become a fresh negotiation every time, and the client controls your calendar.

Keep the amounts in the contract

List every milestone with its amount, or its share of the total, so no invoice ever needs a judgment call. A three-month project might split 30% at signing, 40% at the first delivery and 30% at launch. If a milestone slips, the contract should also say whether its payment slips with it.

This is where payment terms bite, too. If each milestone invoice carries 30 days, a project finished in March can still be unpaid in May. Read what a 30-day payment term really costs before you agree to one on every stage.

Recurring billing is where automation pays off most and where it's easiest to get wrong. The money part is simple: a saved card or a bank mandate gets charged every month or quarter. The hard part is the permission behind it.

Card networks care a great deal about that permission. Visa's stored credential framework says a merchant has to establish an agreement with the cardholder before storing card details for future use. That agreement covers how the stored card will be used, how the cardholder will hear about changes and, where they apply, the cancellation and refund policies. The merchant is expected to keep it for as long as the consent lasts and hand it to the card issuer on request. In real life, that request usually arrives as a chargeback.

Stripe says the same thing from the merchant's side. Its guide to saving payment methods says that to charge a customer who isn't present, your terms should include the customer's agreement to you starting a payment or a series of payments on their behalf, the expected timing and frequency, how the amount is determined, and your cancellation policy if it's a subscription.

Read that list again. It's a description of a well-written recurring billing clause. That's why the signed contract is the natural home for recurring consent: the client reads the amount, the schedule and the way out, signs once, and you keep a dated record of exactly what they agreed to. A pre-ticked box on a payment form proves a lot less. And in the US the e-signature itself isn't the weak point: under the ESIGN Act (the Electronic Signatures in Global and National Commerce Act, 15 U.S.C. § 7001), a contract can't be denied legal effect just because it was signed electronically.

One opinion, for what it's worth. If a client won't sign a clause that says how often you'll charge them and how they can stop it, the recurring arrangement wasn't going to last anyway. Better to learn that before the first charge than at the first dispute. Bank debits follow their own mandate rules, so check what your payment provider asks for before you switch a retainer from card to bank.

Payments fail for dull reasons far more often than dramatic ones. Good billing automation makes the dull ones cheap to fix and saves your energy for the rest.

• Expired or replaced card. The most common cause on recurring billing. Ask the client to update the payment method, then request the payment again.
• Insufficient funds. Wait a few days and try once more. Retrying every day mostly annoys the bank and the client.
• The client disputes the amount: stop retrying and go back to the signed contract. If the terms are clear, it's a short conversation.
• The client goes quiet. Send one reminder that quotes the clause and the due date, then a firmer second one a week later.
• Still nothing after the grace period your contract sets? That's when a formal notice of default earns its place, and the signed contract plus the failed-payment record is your file.

Keep the late-payment terms in the contract itself rather than relying on default rules. Under New York's freelance law, a client whose contract names no payment date owes payment within 30 days of completion (General Business Law § 1411). Elsewhere the defaults differ, which is one more reason to write the date down.

What automation can't do is decide when to stop being polite. That stays your call.

If you already sign contracts in an e-signature tool, check whether it can take the payment too before you buy anything else. Several can, usually on a higher plan than the one small teams start on.

DocuSign is the best-known example. Its payments page says the customer can pay at the point of signing, lists six gateways (Authorize.net, Braintree, Cybersource, Elavon, Stripe and Zuora) and says signer payment methods can be stored for future or recurring charges. That gateway choice is a real advantage for DocuSign if you already hold a merchant account with one of them; Chaindoc's payments run through Stripe. The catch is the plan. DocuSign lists payment collection on Business Pro and its Enhanced plans, not on Personal or Standard.

The table shows where each tool puts payment collection and what that plan costs as the vendor publishes it. Prices move, so treat the dates as part of the data. For a fuller side-by-side, see how Chaindoc compares with DocuSign.

They solve different halves of the same problem, and plenty of businesses end up with both.

When billing automation software is the better buy

Dedicated billing automation software, the category that includes Stripe Billing, Chargebee and Zuora, earns its price when billing itself is complicated. Usage-based pricing, proration when a customer upgrades mid-month, tax across states or countries, revenue recognition, automated dunning, reconciliation synced to your accounting software, hundreds of invoices a month: that's a billing automation system's job, and an e-signature tool won't do it well.

When the contract should do the billing

If your billing is a deposit, a few milestones or a flat monthly retainer, and every engagement starts with a signed agreement, a separate system mostly duplicates data. Automated invoicing from the signed contract covers it, and the terms can't drift between two systems because there's only one.

A practical test: count how often an invoice amount differs from the number in the contract. If the answer is "never, it's always the contract number", you probably don't need automated invoicing software on top. If it's "every month, because usage changes", you do.

Chaindoc sits at the contract end of billing automation. You attach payment terms (amount, schedule, deposit) to the agreement you send for signing. When the client signs, an invoice is generated from the signed contract and the payment runs through Stripe, by card, ACH, SEPA or IBAN transfer depending on the region, with multi-currency support for cross-border deals. The client doesn't need an account. Monthly and other recurring schedules come from the same payment terms, and Stripe, not Chaindoc, stores the card details for them.

On fees, the payments page lists 1% of each payment, with Stripe's and the bank's fees shown separately in Stripe and no monthly charge on the payments side. If a payment doesn't go through, it's marked outstanding and you can send a reminder or request it again from the same place.

What it doesn't try to do

Nothing on the payments page mentions tax calculation, usage-based pricing or an automated dunning sequence. If you need those, run billing software alongside it. One more boundary worth knowing: the blockchain record covers the contract, not the money. The fingerprint of the version you send goes on chain when you publish it, and each signer's proof is added when signing completes, so the terms you billed from can later be checked against that record.

If your work starts with a contract and ends with an invoice, that gap is the first place billing automation should close.