How do you sell a domain to a company that needs an invoice, rather than a wallet address?

Selling a domain to a company that pays through a formal accounts payable process almost always means producing a proper invoice and accepting payment by bank transfer, because most corporate finance departments are structurally set up to pay vendors through purchase orders and invoices, not to send funds to a crypto wallet address, regardless of how the seller personally prefers to be paid. This is less about the buyer being unwilling to use crypto and more about internal processes — accounting systems, audit trails, and approval workflows — that simply aren't built to accommodate a wallet address as a payment destination.

For a domain seller more accustomed to crypto-native deals, this can feel like an unfamiliar shift, but it's a solvable one: the invoice itself is just a formal request for payment, and nothing about producing one prevents a seller from still being paid promptly and securely, as long as the process is approached with the same care any large transaction deserves.

Why do larger companies insist on an invoice instead of a direct payment?

Corporate accounts payable departments exist specifically to create a controlled, auditable record of every payment a business makes — who was paid, for what, approved by whom, and on what terms. An invoice is the standard document that triggers this process: it identifies the seller, describes what's being purchased, states the amount and payment terms, and gives the company's finance team something to match against a purchase order and an internal approval before releasing payment. A request to simply "send crypto to this address" bypasses every one of these internal controls, which is exactly why it's rarely something a company's finance department is equipped or willing to do, independent of any opinion about crypto itself.

This matters beyond mere preference, too — publicly traded companies and many privately held ones have genuine financial reporting and audit obligations that require a traceable paper trail for every vendor payment, and a wallet-address transfer with no accompanying invoice creates exactly the kind of undocumented transaction an audit would flag.

What does a proper domain-sale invoice actually need to include?

A domain sale invoice should look like any standard vendor invoice: the seller's full legal name or business name and contact information, the buyer's company name and billing address, an invoice number and date, a clear description of what's being sold (the specific domain name, and a brief note that this is a sale of the domain asset itself, not a service), the agreed price, payment terms (due on receipt, or a specific number of days), and the seller's preferred payment method and details.

For a sole proprietor or individual seller without an existing invoicing system, a simple, clearly formatted document covering all of this is sufficient — the company's finance team isn't evaluating the invoice's design sophistication, just whether it contains the information their internal process requires to process payment and maintain their own records correctly.

What tax paperwork should you expect to provide as the seller?

A US-based company paying a US-based individual or business for a domain sale will typically request a completed Form W-9 before processing payment, which the company uses to prepare a 1099 form reporting the payment to the IRS if it meets the applicable reporting threshold. This is a standard part of any vendor relationship with a US company, not something specific to domain sales, and providing it promptly is usually the single fastest way to avoid delaying your own payment, since many accounts payable systems simply won't release funds to a vendor without a completed tax form on file first.

For a cross-border sale — a non-US seller working with a US company, or the reverse — the specific form required differs (a Form W-8BEN for a non-US individual, for instance), and it's worth asking the buyer's finance team directly which form applies rather than guessing, since providing the wrong form can cause as much delay as providing none at all.

How do you actually get paid once the invoice is submitted?

Once an invoice is approved internally, most companies pay through ACH transfer or wire, depending on the amount and the company's own standard practice — a larger payment is more likely to go by wire, while routine vendor payments below a certain threshold often go by ACH as a lower-cost default. Payment terms stated on the invoice (due on receipt, net 15, net 30) set the expected timeline, though it's worth asking directly during negotiation what the company's typical payment cycle actually is, since even a "due on receipt" invoice can take longer than expected to actually process through an internal approval chain the seller has no visibility into.

For a domain sale specifically, it's worth confirming the payment timeline relative to the actual domain transfer — whether the company expects to receive the domain before paying, after paying, or whether a third-party escrow service will hold the domain transfer until payment clears, which resolves the same basic "who goes first" problem that applies to any domain sale, covered in more detail elsewhere on this blog.

Can you still get paid in crypto even if the company needs a formal invoice?

Sometimes, though it's less common and worth confirming early rather than assuming. Some companies, particularly those already active in the crypto space themselves, are equipped to process a vendor payment in stablecoin or another crypto asset even while still requiring a formal invoice and standard vendor documentation for their own accounting purposes — the invoice and tax paperwork satisfy the internal audit and compliance requirements, while the actual settlement happens onchain rather than through a bank. This isn't the default for most companies, but it's increasingly available at companies with crypto-native operations or treasury functions, and it's worth asking about directly rather than assuming a formal invoice automatically means a bank-only payment.

For a company not set up this way, a seller strongly preferring crypto settlement has a few practical options: accept the bank payment and convert to crypto afterward through an exchange, which is simple but introduces a brief window of fiat exposure and a conversion step; or, for a larger sale, suggest a payment router that can accept a bank-originated payment on one side and settle a multi-party split or crypto conversion on the other, which some specialized services are starting to offer as the gap between corporate payment systems and crypto settlement narrows.

What happens if the company's process is unusually slow, and how do you protect yourself?

Corporate payment processes, even well-run ones, often take longer than an individual seller used to faster crypto settlement might expect — internal approvals, budget sign-off, and the accounts payable cycle itself can stretch a seemingly simple purchase into several weeks from invoice submission to actual payment. It's reasonable, and common, to ask upfront during negotiation what the company's typical payment timeline looks like, and to build that expectation into when you're willing to release the domain, rather than assuming a large, well-resourced company will necessarily pay faster than a smaller one.

If a company's process is taking unusually long relative to what was discussed upfront, a polite, direct follow-up referencing the invoice number and the agreed payment terms is standard practice — companies that regularly work with vendors expect and accommodate this kind of follow-up as routine, not as an unusual or aggressive request.

Does the size of the sale change how much formality is warranted?

Yes — a modest domain sale to a small company might move through an informal process with a simple invoice and a quick bank transfer, while a substantial six- or seven-figure domain sale to a larger company is more likely to involve a formal purchase agreement in addition to the invoice, potentially legal review on both sides, and a more deliberate payment and transfer process overall. It's worth matching your own expectations and the level of documentation you request to the actual size of the transaction — pushing for an overly formal process on a small sale can slow things down unnecessarily, while treating a large sale too casually risks missing protections (a written agreement specifying exactly what happens if either side doesn't perform) that genuinely matter at that scale.

How does this play out in practice for a seller used to crypto-native deals?

Call her Yuki, a domain investor who'd sold most of her previous domains through crypto-native marketplaces, settling directly wallet-to-wallet with individual buyers and brokers who operated the same way she did. When a mid-sized software company reached out directly wanting to buy a premium domain matching their product name, Yuki initially sent her standard terms — payment to a wallet address upon domain transfer — only to be told by the company's procurement contact that this wasn't something their finance department could process at all, regardless of how much they wanted the domain.

Yuki hadn't prepared an invoice before, and the process felt unfamiliar at first — gathering the company's correct legal entity name, completing a W-9, waiting through what turned out to be a three-week internal approval cycle before payment was actually released. But once she understood what was actually required, it wasn't meaningfully more complicated than any other sale, just structured differently: a clear invoice, a simple written agreement specifying the domain would transfer once payment cleared, and a standard ACH payment that arrived exactly on the timeline the company's procurement contact had described upfront. The domain sold for considerably more than her typical crypto-native deals, in part because corporate buyers with a genuine product need for a specific domain are often willing to pay a meaningful premium — a segment of buyers Yuki would have missed entirely if she'd insisted on crypto-only terms rather than adapting to what the buyer's own process actually required.

Should you negotiate the price differently knowing the buyer requires a formal process?

It's worth factoring the buyer's internal process into your pricing expectations rather than treating it as a reason to discount. A company going through a formal procurement process has typically already internally justified a budget for the purchase before engaging seriously, which often means they've done more due diligence on the domain's value to their specific business than an individual buyer negotiating informally might have — and a company that's cleared internal approval to pursue a specific domain is frequently less price-sensitive than a smaller individual buyer comparison-shopping between several available names. This doesn't mean padding your asking price arbitrarily, but it does mean there's rarely a reason to proactively discount simply because the payment process is slower or more formal than you're used to; the formality of the process and the generosity of the eventual price are mostly unrelated, and if anything the pattern often runs the other way.

It's also reasonable to be direct about your own timeline needs during negotiation — if a company's typical payment cycle runs four to six weeks from invoice to payment, and that doesn't work for you, say so upfront and ask whether an expedited payment option exists, rather than agreeing to terms you're not actually comfortable with and then feeling pressure to chase payment later. Companies that regularly acquire domains or other intangible assets usually have some flexibility here, even if their default process is slower than a crypto-native seller is accustomed to.

What should you do if the company asks you to use their own vendor portal or payment system?

Larger companies increasingly route vendor payments through a dedicated onboarding and payment portal rather than processing invoices manually, which typically means creating a vendor profile, submitting your tax documentation and banking details directly into their system, and then submitting invoices through that same portal going forward. This is standard practice at large, well-run companies and isn't a red flag on its own, but it's worth applying the same basic verification you would to any request for banking details: confirm the portal is genuinely the company's own system (through a link or instruction that came from a verified company contact, not an unsolicited email), and be cautious if a "vendor onboarding" request arrives with urgency or pressure that feels inconsistent with how the rest of the negotiation has gone, since vendor-impersonation fraud targeting exactly this kind of onboarding process is a known and recurring scam pattern covered in more detail elsewhere on this blog.

A legitimate company's procurement or accounts payable contact will have no issue confirming a portal's legitimacy by phone if asked directly, and a seller who takes the extra few minutes to confirm this before entering banking details into an unfamiliar system is protecting themselves against a real and specific fraud risk, not being unreasonably suspicious of a normal business process.

What's the practical takeaway for a domain seller approached by a corporate buyer?

Treat a corporate buyer's need for a formal invoice and bank payment not as an obstacle to work around, but as a normal and often lucrative category of buyer worth being prepared to serve on its own terms. Have a simple invoice template ready, know what tax documentation you'll likely be asked for, confirm the company's payment timeline and process upfront, and still insist on proper sequencing for the actual domain transfer itself regardless of how formal or trustworthy the rest of the process feels. Corporate buyers are frequently willing to pay well for a domain that genuinely matches their brand or product, and the formality of their payment process is a small adjustment relative to the value that segment of the market can represent for a seller otherwise accustomed to a very different kind of transaction.