# Anmelda > Anmelda is a Shopify app that verifies wholesale (B2B) applicants against official business registries and provisions approved buyers as native Shopify B2B companies. ## Key facts - Verifies businesses against EU VIES (VAT ID), the Swiss commercial register (Zefix) and UK Companies House. - Stores the verification result, the number checked and the timestamp with the application, written to the company's metafields on approval. Where VIES returns a consultation number, that is stored too — it is not issued on every check. - Approval workflow: manual one-click approval or auto-approval rules based on verification result and country. - Provisions native Shopify B2B companies, locations and contacts with catalog assignment — no tag-based workarounds. - Checkout lock (Shopify Function) and price hiding until a buyer is approved. - Wholesale application form via theme block or app proxy, in English, German, French and Italian. - Shopify Sidekick app extension: merchants can ask Sidekick for pending applications or an applicant's verification status; approval stays in the app. - EU-hosted (AWS Frankfurt, eu-central-1), GDPR by design: true deletion, per-shop retention window. - Pricing (via Shopify Billing): Free (10 applications/month, all three registries, price hiding and the checkout lock), Growth USD 19/month (100 applications, branded decision emails), Pro USD 39/month (unlimited, auto-approval rules, catalog assignment). ## Links - [Landing page (English)](https://anmelda.gigliotti.software/) - [Deutsch](https://anmelda.gigliotti.software/de/) - [Français](https://anmelda.gigliotti.software/fr/) - [Italiano](https://anmelda.gigliotti.software/it/) - [Setup guide](https://anmelda.gigliotti.software/guide/) (also /de/guide/, /fr/guide/, /it/guide/) - [Shopify App Store listing](https://apps.shopify.com/anmelda) - [Full content](https://anmelda.gigliotti.software/llms-full.txt) — every guide inlined as markdown - [Privacy policy](https://anmelda.gigliotti.software/privacy/) - [Terms of service](https://anmelda.gigliotti.software/terms/) - [Impressum](https://anmelda.gigliotti.software/impressum/) - [Data processing agreement](https://anmelda.gigliotti.software/dpa/) - [Subprocessors](https://anmelda.gigliotti.software/subprocessors/) ## Company Anmelda is made by Gigliotti Software, which builds focused Shopify apps for European commerce. - [Anmelda](https://anmelda.gigliotti.software/) — B2B customer verification & wholesale onboarding (this site) - [Sichta](https://sichta.gigliotti.software/) — AI-agent readiness for Shopify stores - [Rechna](https://rechna.gigliotti.software/) — German/EU e-invoicing for Shopify ([App Store](https://apps.shopify.com/rechna)) - [Angaba](https://angaba.gigliotti.software/) — GPSR product disclosures for Shopify Contact: hello@gigliotti.software --- # Guides (full text) ## Wholesale applicant data under GDPR: why deletion beats anonymisation > Rejected applications are where wholesale data liability accumulates. What to retain, for how long, why a company name plus VAT number re-identifies a sole trader, and what belongs in the privacy notice. Wholesale applications collect exactly the data that GDPR treats most carefully: names, business addresses, contact details, and sometimes a passport-adjacent identifier. Most stores handle the approvals well and the rejections badly — the applicant you turned down is the one whose data you have no lawful reason to keep, and "we anonymise it" is usually not the answer people think it is. This guide covers what to keep, for how long, and why deletion beats anonymisation for business applicants. ## The rejected applicant is the hard case An approved applicant becomes a customer: you have a contract, a company record, orders, and invoices you are legally required to retain. The lawful basis is clear and the retention period is set by tax law, not by preference. A rejected applicant has none of that. There is no contract, no ongoing relationship, and after the decision is communicated there is usually no purpose left. GDPR's storage limitation principle (Art. 5(1)(e)) says data may be kept no longer than necessary for the purposes it was collected for — and once you have decided not to trade with someone, the application has served its purpose. The usual objection is that you want a record in case they reapply, or in case of a dispute. Both can be legitimate, but both need to be stated as a purpose with a retention period attached, not left as a vague intention. A defensible position looks like: "rejected applications are deleted after 90 days; we retain the decision and its date for 12 months to handle reapplications and disputes." What is not defensible is keeping the full application indefinitely because nobody built the deletion path. ## Why anonymisation usually fails here Anonymisation is attractive because it removes the data from GDPR's scope entirely — anonymous data is not personal data. The catch is the standard: data is only anonymous if re-identification is not reasonably possible by anyone, using any means reasonably likely to be used. Business applicant data rarely clears that bar. A company name plus a VAT number is a public registry lookup away from a named human — that is precisely what registries are for. For a sole trader, the company name frequently is the person's name. Strip the contact name and email, keep "Müller Handel, DE123456789, applied 4 March, rejected", and you have a record that identifies an individual to anyone with a browser. So the pattern of "anonymise instead of delete" that works for web analytics does not transfer to B2B applications. Deletion is simpler, cheaper to explain, and actually achieves the goal. If you want to keep statistics, keep counts — applications per month, approval rate — not de-identified rows. ## Who is the controller? This gets muddled when an app is involved. The merchant decides to run a wholesale program, decides the questions on the form, and decides who gets approved: the merchant is the controller for applicant data. An app processing that data on the merchant's behalf is a processor, and needs an Art. 28 data processing agreement to be lawful. Two practical consequences. First, the retention period is the merchant's decision, not the app's default — so it should be configurable, and the app should not quietly keep data longer than the merchant told it to. Second, when an applicant exercises their rights, the request lands with the merchant, and the app has to be able to answer it: find the record, export it, delete it. An app that cannot delete a single applicant on request is not usable by a controller who has to comply. ## Registry lookups and data minimisation Verification is a place where it is easy to send more than necessary. Checking a business against VIES, Zefix or Companies House requires a company identifier — a VAT number, a registry number. It does not require the applicant's name, email or address, and sending those to a third party would be processing without a purpose. Keep the split clean: the registry receives the identifier and returns a status; the applicant's personal details never leave your systems. That is both minimisation in the Art. 5(1)(c) sense and a much shorter answer when someone asks what your subprocessors receive. Do keep the evidence of the check. For intra-EU supplies the validity of the buyer's VAT ID is a substantive condition of zero-rating, so the VIES consultation ID and the date belong in your records — attached to the company, not floating in a log. That is a retention purpose with a real legal basis behind it, and it is worth distinguishing from the application itself. ## What belongs in the privacy notice The wholesale form is a collection point, so it needs its own paragraph rather than a link to a general policy. What applicants should be able to read before submitting: - What is collected, and which fields are required versus optional. - That the business details are checked against public registries, and which ones. - How long an application is kept if approved, and if rejected — with actual numbers. - Who processes it besides you, and where (hosting region matters to European buyers). - How to request access or deletion, and that a decision is not made by automated means alone — or, if it is, say so, because Art. 22 attaches rights to that. That last point is worth care. Auto-approval rules are convenient and defensible for low-risk cases, but "your application was rejected automatically" is a different legal position from "we reviewed it". If rejections are automated, applicants have a right to human intervention. ## A retention model that holds up A structure that covers the realistic cases: - Approved and became a customer — retained under the customer relationship; invoices follow tax-law retention (in Germany, 8 years for invoices), not the application's schedule. - Approved but never ordered — a company record with no transactions. Give it an expiry: if there is no order within, say, 24 months, it is a dormant record with no purpose. - Rejected — delete the application on a short clock; keep the decision and date only as long as you have a stated reason. - Withdrawn or abandoned — a half-finished form is data you never had a use for. Delete it soonest of all. Whatever the numbers, the sweep has to actually run. A retention policy that exists only in a privacy notice is worse than none: you have published a promise you are breaking. ## The short version Applicant data is the liability in a wholesale program, and rejections are where it accumulates. Delete rather than anonymise, because a company name plus a VAT number re-identifies a sole trader. Send registries an identifier and nothing else, but keep the verification evidence with a legal basis of its own. Put real retention numbers in the privacy notice, make them configurable by the merchant who is the controller, and make sure something automated enforces them. Plain-language summary, not legal advice — retention periods and the lawful basis for your specific program are worth a lawyer's half hour. ## Shopify B2B catalogs and price lists: what the 3-catalog limit forces you to decide > Direct company-location catalogs are Plus-gated; B2B market catalogs cap at 3 active. How to model wholesale tiers, currencies, quantity breaks and payment terms inside those limits. Shopify's native B2B gives every wholesale customer a company, a location and a catalog with its own price list. What it does not give you is a way to assign a catalog directly to a company location unless you are on Shopify Plus — and that single entitlement decides how you have to model wholesale pricing. This guide covers the two mechanisms, the limits each carries, and how to build wholesale pricing that works on both. ## The two ways to price for a B2B buyer Native B2B separates who the buyer is (a company with locations and contacts) from what they see (a catalog containing a price list). Attaching the second to the first happens one of two ways. Direct company-location catalogs. A catalog is assigned to specific company locations. This is the precise mechanism: this buyer, this location, these prices. It is also entitlement-gated — attempting the assignment without the entitlement fails with UNPERMITTED_ENTITLEMENTS_DIRECT_CATALOG_ASSIGNMENT, which in practice means Shopify Plus. B2B market catalogs. A catalog is attached to a B2B market, and company locations belong to that market. Available on standard plans, but with a hard ceiling: a shop can have at most 3 active B2B catalogs of this kind. Exceed it and catalog creation fails with B2B_CATALOG_LIMIT_REACHED. Those two error codes are the whole design constraint. Any wholesale app or custom build has to pick a strategy per shop, and the only honest way to know which applies is to try the assignment and read the error — plan names are not a reliable proxy, since entitlements move. ## What "3 active catalogs" forces you to do Three is enough for pricing tiers and not enough for pricing per customer. If your model is "every wholesale account negotiates its own prices", the market-catalog path cannot express it on a standard plan, and no amount of engineering works around the limit. What does fit in three: - Tiered wholesale — for example Bronze / Silver / Gold at 20% / 30% / 40% off retail, with each company location assigned to the market matching its tier. This covers the majority of real wholesale programs. - Regional pricing — one catalog per currency or region, with tier handled through quantity breaks inside the price list instead. - A trial tier plus two real tiers — useful when new accounts get standard wholesale until they prove volume. If you genuinely need per-account pricing, that is a Plus conversation, and it is better to have it before you promise a customer bespoke rates. ## Price lists: fixed prices or relative adjustments Inside a catalog, a price list sets prices either as an adjustment relative to the product's price (a percentage off, applied across the board) or as fixed prices per variant. Both have a place, and mixing them badly is a common source of surprise. A percentage adjustment stays correct when retail prices change — raise a retail price and wholesale follows. Fixed prices do not: they are a snapshot, and they silently go stale. If your margins depend on the relationship between the two, adjustments are safer. If your wholesale prices are genuinely independent of retail (contract pricing, price-per-kilo, catalog pricing), fixed prices are the honest representation and you accept the maintenance. Quantity breaks live in the price list too, which is how "cheaper by the case" works without a separate catalog per volume tier — worth exhausting before you spend one of your three catalogs on a volume band. ## Currency, and why it constrains catalogs A B2B catalog is tied to the currency of its market. Selling wholesale in EUR and CHF is therefore two catalogs before you have expressed any tiering at all — half your budget on a standard plan. It is worth deciding early whether you are running multi-currency wholesale or multi-tier wholesale, because on three catalogs you rarely get both. ## Payment terms belong to the company, not the catalog A frequent modelling mistake: trying to express net-30 as a pricing concept. Payment terms attach to the company (and its locations) as a payment-terms template, independent of which catalog they see. Prices and terms are separate axes — a buyer can be on your best tier and still pay up front, or on standard pricing with 30 days to pay. Keeping them separate also keeps verification meaningful: granting terms is a credit decision, while a registry check tells you a business exists and is registered. Those are different questions, and conflating them is how unpaid invoices happen (see our guide to VAT ID verification). ## Getting a new account onto the right prices The sequence that works, and the order matters: - Create the company and at least one location. The location, not the company, is what carries tax settings, payment terms and catalog membership. - Create the contact and link it to the customer account, so the buyer signs in and lands in B2B context rather than retail. - Assign to the market or catalog according to the strategy the shop's entitlements allow. - Set tax exemption where it applies — an intra-EU B2B buyer with a valid VAT ID is usually exempt, and this is the setting that decides whether their invoices come out with or without VAT. - Record the verification evidence on the company as metafields, including the VIES consultation ID when the registry issues one. Six months later, "why did we zero-rate this?" needs an answer. Each step can fail independently, which is why provisioning should be resumable rather than a single transaction — a half-created company with no catalog assignment is a customer who signs in and sees retail prices. ## The short version Direct company-location catalogs are precise and Plus-gated; B2B market catalogs work everywhere but cap at three active. Decide whether your three go to tiers or to currencies, use price-list adjustments rather than fixed prices unless wholesale is genuinely independent of retail, put quantity breaks in the price list instead of spending a catalog on them, and keep payment terms on the company where they belong. Probe the entitlement rather than guessing from the plan name — the two error codes above are the ground truth. ## Native Shopify B2B companies vs tag-based workarounds: an honest comparison > Companies, locations and catalogs vs. customer tags and theme tricks: a dimension-by-dimension comparison, when tags are genuinely fine, the Plus question answered precisely, and a migration path. Native Shopify B2B represents a wholesale buyer as a company — with locations, contacts, catalogs, price lists and payment terms built into the platform — while tag-based workarounds approximate wholesale by putting a tag on a retail customer record and wiring discounts and price-hiding around it in theme code. Both approaches are widespread, and the honest answer to "which one?" is: it depends on what your wholesale business actually needs. This guide compares them dimension by dimension, says when tags are genuinely fine, and maps the migration path for when they stop being fine. ## How each approach models a buyer Under native B2B, "Acme GmbH" exists in Shopify as a company: it has one or more locations (each with its own address, tax context and catalog), and contacts — real people linked to the company who log in and order on its behalf. Wholesale pricing lives in catalogs and price lists attached to the company, and B2B-specific checkout behaviour (payment terms, PO numbers) hangs off the same structure. Under a tag workaround, "Acme GmbH" is a retail customer record — usually one person's email — carrying a tag like wholesale. The theme checks the tag to show or hide prices; discounts or scripts apply a percentage off; and everything the tag cannot express (multiple buyers per company, per-location pricing, net terms) either does not exist or is faked with more tags. That difference in data model is the root of every difference that follows: one approach has an organisation as a first-class object; the other has a label on an individual. ## The comparison DimensionNative Shopify B2BTag-based workaround Data modelCompany → locations → contacts; the org structure is realA tag on an individual customer record; no company object Pricing controlCatalogs and price lists: per-company fixed prices or adjustments, per locationBlanket percentage discounts; per-customer nuance means tag sprawl and theme logic Checkout experienceB2B checkout: payment terms, PO numbers, company context on the orderRetail checkout with a discount; terms handled off-platform (invoices by email) Customer accountsContacts see their company, its orders and terms in the accountA personal retail account; colleagues share a login or get separate tagged accounts ReportingOrders carry the company; wholesale revenue is filterable nativelyReconstructed from tag filters; breaks silently when tags drift Theme dependencyPlatform-level; survives theme swapsPrice-hiding and gating logic re-implemented in every theme change Migration effort—Grows with every tagged customer and every theme customisation added Plan availabilityCompanies, locations, contacts and payment terms on every Shopify plan; direct location-catalog assignment is Plus-only — non-Plus stores use B2B market catalogs with price lists (max 3 active)Any plan ## When tags are actually fine An honest comparison admits the tag approach has a legitimate zone. Tags are a reasonable choice when all of these hold: - Wholesale is a side channel — a handful of trusted buyers, not a funnel of applicants you need to verify. - Pricing is a single blanket discount ("wholesale gets 30% off everything") rather than negotiated per-account prices. - You do not need payment terms, PO numbers, or multiple buyers per company — one person per business, paying at checkout, is your reality. - Your theme is stable and you accept re-wiring the price-gating when it changes. In that zone, tags are simpler to set up and there is no shame in them. The trouble is that the zone has sharp edges, and growing wholesale businesses exit it quietly: the second buyer at the same company, the first request for net-30 terms, the first per-account price sheet — each is a feature the tag model structurally cannot express. ## When native wins Native B2B wins the moment wholesale is a real channel with real structure: - Verified onboarding. A wholesale application funnel — form, register verification, approval — needs somewhere real to land. Approving an applicant into a native company with a location and a contact is provisioning; approving into a tag is bookkeeping. (See the wholesale application workflow guide for the full funnel, and the VAT ID verification guide for the verification stage.) - Negotiated pricing. Fixed per-account prices, currency-specific price lists, per-location catalogs — this is what catalogs and price lists are for. - Organisational buying. Several people ordering for one company, each with their own login, all visible on the company's order history. - B2B checkout mechanics. Payment terms and PO numbers at checkout instead of "we'll invoice you by email". - Clean reporting and clean exits. Wholesale revenue is a filter, not an archaeology project — and no tag/theme spaghetti to unwind later. ### The Plus question, precisely A persistent myth says native B2B requires Shopify Plus. The accurate version: creating companies, locations, contacts and payment terms works on every Shopify plan. What is Plus-only is assigning a catalog directly to a company location. Non-Plus stores achieve wholesale pricing through B2B market catalogs with price lists instead, which Shopify caps at three active catalogs — enough for tiered wholesale pricing (say, standard / silver / gold), not for hundreds of individually negotiated catalogs. A capable app detects the store's plan at runtime and picks the right catalog strategy automatically; Anmelda does exactly this, so the same approval flow provisions correctly on Plus and non-Plus stores alike. ## Five questions that decide it If the table still leaves you undecided, these questions usually settle it: - Will two people from the same company ever need to order? If yes, you need a company object with contacts — a tag on one person's account cannot express it. - Will any buyer ever pay on terms instead of at checkout? Payment terms are native B2B functionality; with tags they live in a spreadsheet and an email thread. - Is any price negotiated per account rather than a blanket percentage? That is a price list, not a discount code. - Do you need to verify applicants before they see wholesale prices? A verification-and-approval funnel needs a real provisioning target to land on. - Might you change your theme in the next two years? Every theme change re-opens tag-based gating; native B2B does not notice a theme swap. One "yes" is a lean toward native. Two or more are a decision. ## The migration path Moving from tags to native B2B is mostly an exercise in making implicit structure explicit: - Inventory the tagged customers. Which tags mean "wholesale"? Which customers belong to the same real-world company? This grouping is the actual work. - Verify while you migrate. Migration is the natural moment to check each business against the registers (VIES, Zefix, Companies House) — you are re-founding the relationship on clean data. - Create companies, locations and contacts — one company per real business, locations from their billing/shipping addresses, existing customer records linked as contacts (order history stays with them). - Rebuild pricing as catalogs and price lists, replacing blanket discount logic. - Retire the theme workarounds. Remove tag-based price hiding once companies carry the pricing; keep gating only for not-yet-approved visitors. - Run both briefly, then cut over. Tags can coexist with companies during the transition; set an end date so they actually get removed. New wholesale applicants should land on the native side from day one — there is no reason to add to the pile you are migrating away from. That is the role of an application-and-verification layer in front of provisioning: from the first day of the migration, every newly approved buyer is already a native company. It is precisely the funnel Anmelda automates — verified applications in, native Shopify B2B companies out, no tags anywhere in between. ## VAT ID verification for Shopify B2B: how VIES works and why the consultation ID matters > How VIES VAT ID checks really work for Shopify wholesale: simple vs. qualified confirmation, the consultation ID as audit proof, downtime and retries, plus Swiss and UK equivalents. VAT ID verification is the process of confirming that a customer's VAT identification number is currently registered with the tax administration of an EU member state — not merely that it looks like one. For a Shopify store selling wholesale, that distinction decides whether a B2B applicant is a real, registered business or a plausible-looking string of characters. The EU's official lookup service is VIES, and one detail of a VIES check — the consultation ID — matters far more than most merchants realise. ## What a VAT ID is (and what it is not) Every business registered for VAT in the EU receives a VAT identification number: a two-letter country prefix followed by a country-specific pattern of digits and letters — DE123456789 for Germany, FR12345678901 for France, NL123456789B01 for the Netherlands. The number identifies the business for cross-border VAT purposes, and it is the key that unlocks the most common B2B tax treatment in Europe: an intra-Community supply, where the seller can zero-rate the invoice and the buyer self-accounts for VAT in their own country. That tax treatment is exactly why verification matters. If the buyer's VAT ID turns out to be invalid, expired or someone else's, the tax office can come back to the seller for the VAT that was never charged. A VAT ID on an application form is a claim; verification turns it into evidence. ## How a VIES lookup actually works VIES — the VAT Information Exchange System, run by the European Commission — is often described as a database, but it is not one. It is a relay: when you query a VAT number, VIES forwards the request in real time to the national VAT registry of the member state in the country prefix and returns that registry's answer. There is no central copy of the data, which has two practical consequences: - The answer is authoritative. A "valid" response comes from the member state's own registry at the moment you asked, not from a cached mirror. - Availability is only as good as 27 national systems. If one member state's registry is down for maintenance — which happens routinely, often overnight — VIES cannot answer for that country, no matter how healthy the rest of the system is. ### Simple vs. qualified confirmation Tax practice distinguishes two levels of confirmation. A simple confirmation answers one question: is this VAT number valid right now? A qualified confirmation goes further: it also returns (or checks) the name and address registered to the number, so you can confirm the VAT ID actually belongs to the business that applied — not to some unrelated company whose number was copied off an invoice. German merchants know this distinction from national law: the confirmation procedure for foreign VAT IDs is anchored in § 18e of the German VAT Act (UStG), under which the Federal Central Tax Office (BZSt) confirms the validity of another member state's VAT ID and, on request, the registered name and address. Whichever route you use — the BZSt procedure or VIES directly — the principle is the same: for audit purposes, a qualified, documented check is worth far more than a quick validity ping. For a wholesale application, always compare the registered name against the company name the applicant typed into your form. ### The consultation ID: proof you actually checked Here is the detail that separates a serious verification setup from a casual one. When you query VIES and identify yourself with your own VAT number as the requester, VIES issues a consultation ID (a request identifier such as WAPIAAAAY…). That ID is the official, legally recognised record that a specific check on a specific number took place at a specific time. Why it matters: tax audits happen years after the sale. If an auditor questions a zero-rated B2B invoice from three years ago, "we checked the VAT ID at the time" is an assertion — a stored consultation ID is proof. The buyer's number may have been deregistered since; the consultation ID pins your good faith to the date of the check. A verification process that throws this identifier away is doing the work and discarding the receipt. Two practical notes: VIES only issues a consultation ID when the requester supplies their own member state and VAT number with the query, and the ID should be stored with the application it belongs to, not in a log file that rotates away. Anmelda stores the result and a timestamp with every application by default; the consultation ID is captured too whenever the check runs with a requester identity — ask if you need that configured for every application. ## Format check vs. registry check A surprising number of "VAT validation" tools only check the format: the right country prefix, the right number of characters, sometimes a checksum. A format check is useful as a first gate — it catches typos instantly, before any network call — but it verifies nothing about the real world. DE123456789 is perfectly formatted and almost certainly not a registered business. A robust pipeline does both, in order: validate the format locally (instant feedback, no wasted lookups), then confirm against the registry (the actual verification). Treat any tool that stops at step one as a typo filter, not a verification. ### How often should you re-check? Validity is a snapshot: a VAT number that was registered in January can be deregistered by June — businesses close, merge and lose their registration. A pragmatic cadence is to verify at application time (always, with the result and timestamp stored) and to re-verify before events that matter: a large first order, reactivating a dormant wholesale account, or a periodic review of your active B2B customers. Each re-check earns its own timestamped record, extending the documented chain of good faith rather than leaving it anchored to a single date years in the past. ## When VIES is down — and it will be Because VIES relays to national registries, downtime is a normal operating condition, not an exception. The service publishes explicit error codes for it: MS_UNAVAILABLE (the member state's registry is offline), MS_MAX_CONCURRENT_REQ and GLOBAL_MAX_CONCURRENT_REQ (load limits), SERVICE_UNAVAILABLE and TIMEOUT. Member-state registries are routinely taken offline for nightly maintenance windows. The critical design decision: these codes mean "try again later", never "this VAT number is invalid". A workflow that shows a wholesale applicant as "failed verification" because the Spanish registry was down at 2 a.m. will reject legitimate buyers and poison your approval data. The correct behaviour is to queue the check and retry automatically until the registry answers — which is how Anmelda's verification engine treats every one of those codes, distinguishing "the source said no" from "the source didn't answer". ## Beyond the EU: Switzerland and the UK European wholesale rarely stops at the EU border, and neither should verification. Switzerland and the UK each have an official, queryable register: EUSwitzerlandUnited Kingdom RegisterVIES (relays to national VAT registries)Zefix — central index of the commercial registerCompanies House IdentifierVAT ID, e.g. DE123456789UID, e.g. CHE-123.456.789Company number, e.g. 12345678 What it confirmsVAT registration valid now; name/address where the member state returns themCompany exists; status, registered seat, legal formRegistration status, company name match, incorporation date Proof artefactResult and timestamp (plus a consultation ID when the check runs with a requester identity)Register extract data at time of checkRegister data at time of check The pattern is the same in all three: an official register, a structured identifier, and an answer worth storing. What differs is what is confirmed — VIES confirms VAT registration, Zefix and Companies House confirm corporate existence and status. For Swiss and UK applicants, register status is your equivalent of the VIES check. ## Putting it into a Shopify wholesale workflow Verification is one stage of a longer funnel: a buyer applies, the registers are checked, a human (or a rule) approves, and the buyer becomes a native Shopify B2B company with the right catalog and terms. We walk through the full funnel in our guide to the wholesale application workflow, and compare provisioning approaches in native B2B vs. tag-based workarounds. The short version of what good looks like: format-check instantly, registry-check automatically on submission, retry through downtime instead of failing applicants, compare the registered name against the application, and store the result, the number checked and the timestamp with the application record — the consultation ID too, whenever VIES issues one. That is precisely the pipeline Anmelda ships for Shopify — VIES, Zefix and Companies House checks queued on submission, with the result and timestamp kept as an audit record. ## Shopify wholesale applications: form, verification and approval workflow done right > The full B2B application funnel for Shopify: which form fields matter, automatic register checks, manual review vs. auto-approval rules, and what approval must actually provision. A wholesale application workflow is the path a business buyer travels from "request B2B access" to placing a first order at wholesale terms: an application form, an identity and register verification, an approval decision, and the provisioning that actually unlocks buying. Most Shopify stores get one or two of those stages right and improvise the rest — a form that asks too much, checks done by hand in a browser tab, approvals that create a customer tag and hope for the best. This guide walks the full funnel and what "done right" looks like at each stage. ## Stage 1: the application form The form has one job: collect exactly what verification and provisioning will need, and nothing else. Every extra field costs conversions; every missing field costs a follow-up email. ### Fields that matter - Company name — as registered, because you will compare it against register data. - Business address and country — the country routes the verification (EU → VIES, Switzerland → Zefix, UK → Companies House), and the address becomes the B2B company location on approval. - VAT ID or company register number — the verifiable identifier. Which one applies depends on the country. - Contact person and email — this person becomes the company contact who logs in and orders. - Phone, website, expected order volume, free-text message — optional but cheap, and genuinely useful for manual review judgement calls. ### Fields to skip Resale certificates as upload requirements (a European register check is stronger and frictionless), bank details (never on an application form), multi-page questionnaires, and anything you can look up yourself from the register number. A wholesale application form is a qualification gate, not onboarding paperwork. This is why Anmelda ships a prebuilt B2B field library — company details, contact, business address, VAT number, register number, phone, website, expected volume, message — rather than a generic form builder: the field set is the product of what the downstream stages actually consume. One more constraint shapes the form: it collects business data about real people, so it falls under the GDPR. Collect only what you will use, host it in the EU if your buyers are European, and delete rejected applications once a defined retention window passes — an applicant who never became a customer is not a marketing asset to keep forever. (Anmelda hosts applicant data in Frankfurt, eu-central-1, and erasure means true deletion, not anonymisation.) ## Stage 2: verification before a human looks The moment an application arrives, the verifiable claims in it should be checked against official registers — automatically, in the background, before anyone opens the application. An EU VAT ID goes to VIES; a Swiss UID goes to Zefix (status, registered seat, legal form); a UK company number goes to Companies House (status, company name match, incorporation date). We cover the mechanics — including simple vs. qualified confirmation and why the VIES consultation ID must be stored — in the VAT ID verification guide. Two properties make automated checks trustworthy. First, retries: registries go down routinely, and a temporary outage must never surface as a failed applicant. Second, honest states: a check can pass, fail, error, or simply not apply (a Norwegian applicant matches none of the three registers). The review UI should show which, per source — a traffic light, not a single boolean. ## Stage 3: the decision — manual review vs. auto-approval Manual review is the default and should stay available forever: a reviewer sees the application next to the register results — does the registered name match the form? is the company active? — and approves or rejects with one click. Auto-approval is an optimisation for the unambiguous cases, and it is only safe with strict preconditions. A sane rule auto-approves an application only when all of the following hold: - at least one register check applied and every applicable check passed — fully green, no ambers; - an applicant that no register covers is never auto-approved — no evidence means a human decides; - if a country allowlist is configured, the applicant's country is on it; - the application is still untouched — a rule must never overrule a reviewer who already started. This is precisely how Anmelda's auto-approval rules (a Pro-plan feature) are built: green-only, allowlist-aware, and never for applicants outside register coverage. The failure mode to avoid is the inverse workflow — auto-approve by default, verify later — which converts your wholesale channel into an honour system. ## Stage 4: what approval must actually do Approval is where most home-grown workflows quietly fall apart, because "approved" has to become real Shopify state. On a native B2B setup, one approval should produce all of this: StepWhat is createdWhy it matters CompanyA native Shopify B2B companyThe buyer is an organisation with orders, terms and metadata — not a tagged retail customer LocationA company location from the application's business addressShipping, tax and catalog context attach to the location ContactThe applicant linked as the company's main contactThis is who can log in and order at B2B terms CatalogWholesale catalog assignment (plan-dependent, see below)The buyer sees wholesale prices, everyone else does not UnlockCheckout lock and price hiding lift for the approved buyerThe gate that kept prices hidden opens automatically EmailA decision email to the applicantThe buyer learns they can now order — nobody checks a portal daily One plan nuance worth knowing: Shopify creates companies, locations and contacts on every plan, but assigning a catalog directly to a company location is a Shopify Plus feature. On non-Plus plans the equivalent is a B2B market catalog with a price list — capped by Shopify at three active catalogs. A well-built app detects what the store's plan supports and picks the right strategy automatically; the comparison guide covers this in depth in native B2B vs. tag workarounds. Provisioning must also be resume-safe. It is a multi-step sequence of API calls, and any step can fail transiently. If step four fails, rerunning must continue from step four — not create a second company. Idempotent, resumable provisioning is the difference between an approval button you trust and one you click while watching the admin with your other eye. ## Stage 5: decision emails Both outcomes deserve an email. The approval email should say what changed ("your wholesale access is active"), where to log in, and what the buyer will see. The rejection email should be polite, brief and honest — and when the reason is fixable (a VAT ID typo, a missing register number), say so and invite a corrected application. A silent rejection costs you a buyer who might have been one digit away from legitimate. ## Common mistakes MistakeConsequenceFix Form asks for everything imaginableLegitimate buyers abandon the applicationCollect only what verification and provisioning consume Manual register lookups in a browser tabSlow approvals; no stored proof of the checkAutomated checks on submission, results stored on the application Registry downtime shown as "failed"Legitimate applicants rejected for a maintenance windowDistinguish "source said no" from "source didn't answer"; retry the latter Auto-approving unverifiable applicantsThe gate stops gating exactly where evidence is weakestAuto-approve only fully green, register-covered applications Approval = adding a customer tagNo company, no locations, no B2B checkout, no payment termsProvision a native B2B company, location, contact and catalog Discarding the VIES consultation IDNo audit-proof record that you verified in good faithStore the consultation ID with the application No decision emailApproved buyers never notice; rejected ones apply againEmail both outcomes, with next steps ## The workflow, end to end Form → automatic register checks → traffic-light review (or a strict auto-approval rule) → native B2B provisioning → decision email. Each stage feeds the next, which is why bolting them together from separate tools tends to leak: the form does not know what verification needs, verification does not write to the approval queue, approval does not provision. Anmelda was built as this funnel in one piece — application form (theme block or app proxy), VIES/Zefix/Companies House checks with stored proof, an approval inbox with auto-approval rules on Pro, resume-safe native B2B provisioning, and decision emails — so a wholesale applicant becomes an ordering B2B customer without a single manual copy-paste in between.