E-Commerce Platforms & Shop Systems
Sana Commerce
EU-Made Report an errorPanel rating · 6 judges · How to read the stars
Category median
Sovereignty: 1 of 4 dimensions proven
0–5 in half steps. 5 means the rubric's top anchor is met on the evidence.
by Sana Commerce B.V. · www.sana-commerce.com
Report an error on this page Is this your product? →
Read this page as one judge. Each weighs the same scores by what they care about.
The panel's verdict
Sana Commerce is a B2B e-commerce platform sold by Sana Commerce EMEA B.V. of Rotterdam and built directly on the merchant's ERP. It is strongest at operations, scoring 3-6, where real-time synchronisation of stock, prices and order information plus self-service through to reordering does the work — though the supported ERP systems are never named and returns, carriers and partial shipments go unevidenced. It is weakest at tax & German legal correctness, extensibility and pricing transparency: the evidence says nothing on VAT determination, OSS or German checkout legal texts, and no API, themes or app ecosystem appears. The judges genuinely split on operations — over how far an unnamed ERP backbone carries the post-checkout story — and on data ownership & exit, where structural ownership of master data in the ERP collides with total silence on export and migration. Sovereignty lands at 3-4: an NL contracting entity whose data residency, ownership and subprocessors are unknown, with a USA support line in the imprint. Persona-weighted totals range from 1.6 to 2.7; pricing is unpublished.
Speaks for it
- Real-time ERP sync of stock, prices and order information is documented on the homepage and anchors the operations scores of 3-6
- Personalised catalogs, ERP-based recommendations and intelligent product search give the catalogue side substance
- Self-service from product search through to reordering is a documented claim
- The contracting entity is Sana Commerce EMEA B.V. of Rotterdam — KvK 24275452, VAT ID NL857142677B01
- The ERP-as-source-of-truth architecture keeps master data on the merchant's side, which judges credit as structural but inferential
Held against it
- Nothing on VAT determination, OSS, reverse charge, VAT-ID validation or mandatory German checkout legal texts (tax & German legal correctness 0-1)
- No API, themes, app or plugin ecosystem, or developer surface appears anywhere in the evidence
- The checkout path itself is unevidenced — payment methods, guest ordering, variants, bundles and promotion rules are absent
- Returns, refunds, carriers, label printing, partial shipments and the names of supported ERP systems are missing from the evidence
- No export, hosting, deletion or migration statement exists, splitting data ownership & exit from 0 to 4
Best for
- You run B2B commerce on an ERP you trust and want the webshop to mirror stock, prices and order information in real time
- Your buyers self-serve — intelligent product search, personalised catalogs and reordering are the vendor's documented claims
- You sell into the manufacturing and machinery industries the vendor names
- Your ERP is already your master-data system and you want a shop that projects it rather than duplicating it
Avoid if
- You need documented tax handling — VAT determination, OSS, reverse charge or German checkout texts — before launch
- You must establish data residency or a subprocessor list before signing
- You need an evidenced exit path or export tooling for shop data — the evidence offers neither
The scores
Catalogue & checkout
panel disagrees
Show reasoningHide reasoning
How this is scored
Products, variants, pricing rules and the path to payment — the part that either converts or does not.
0 — Flat product list with one price and no variants; checkout is a form and one payment method.
3 — Variants and categories with a standard checkout and two or three payment methods, but no bundles, no tiered pricing and no guest checkout worth the name.
5 — Full variant matrix, product bundles, tiered and customer-group pricing, guest checkout, and the payment methods a German shop needs including invoice and direct debit.
8 — Configurable products, per-channel pricing, promotions and vouchers with rules, a checkout that can be customised without a rebuild, and payment via the major providers plus buy-now-pay-later where offered.
10 — Merchandising and checkout are the product: rule-driven pricing and promotions, A/B-testable checkout, multi-currency and multi-language as standard, and conversion features (abandoned cart, one-page checkout) shipped rather than bolted on.
The Merchant
The variant story is real — matrix and dropdown modes, side-by-side comparison, unlimited components — and 24 Adyen payment methods including SEPA Direct Debit, Giropay and three Klarna buy-now-pay-later variants cover most of what a German checkout expects. But promotions and price rules are what sell, and on bundles, tiered or customer-group pricing, checkout customisation, abandoned cart and one-page checkout I found no public information. 1 3 4
The B2B Seller
Variants are the real thing — managed in the ERP, displayed as a matrix or dropdowns with no limit on components, and the B2B list view opens the full variant matrix, which is how trade buyers actually order. Payment coverage is broad: twenty-four methods via Adyen including International Bank Transfer, SEPA Direct Debit, iDEAL, Sofortüberweisung, Giropay and Klarna, saved cards for repeat purchase without a redirect, and guests can order without registration. We found no public information on bundles, tiered pricing, promotions or vouchers, so the pricing-and-promotion engine beyond ERP-synced prices stays unevidenced. 1 3 4
The Developer
Variants are the strong part — a real matrix or dropdown display with unlimited components, translated names, side-by-side variant comparison, all managed in the ERP — and checkout reaches 24 payment methods via Adyen including SEPA Direct Debit, iDEAL and three Klarna buy-now-pay-later options, with guest ordering at least configurable. We found no public information on bundles, tiered or customer-group pricing rules in the shop, or promotions and vouchers, and variant support itself varies by ERP. Merchandising rules, as far as the pages show, live in the ERP; payments are the evidenced strength. 1 3 4
The Operations Lead
Variants are genuinely strong — ERP-driven matrix and dropdown views with unlimited components, all-variants comparison on one page, and translated names — and the payment path covers twenty-four methods including SEPA Direct Debit, Giropay, Sofortüberweisung and Klarna, with one-click saved cards and no redirect to a hosted page. We found no public information on bundles, tiered or customer-group pricing, promotions or vouchers, so what is documented is a solid variant-and-payment core without the merchandising rules layer. 1 3 4
The Data Protection Officer
Variant handling is real and deep — matrix or dropdown presentation across seven named ERP systems, all variants compared on one page, translatable variant names — and the payment set is broad, twenty-four methods including direct debit and Klarna pay-later, with guest ordering referenced in the payment documentation. I found no public information on bundles, tiered or customer-group pricing rules, or promotions and vouchers; pricing in fact arrives live from the ERP rather than from any rule engine I can see. One caution: the captured pages give different states for the payment add-on, with the Adyen Checkout add-on marked deprecated in favour of Sana Pay. 3 4 1
The Skeptic
Variant handling is genuinely deep — matrix or dropdown display, unlimited variant components, a B2B variant matrix view — and the Adyen provider's list of 24 payment methods covers giropay, Sofort, SEPA direct debit and Klarna buy-now-pay-later. But that list attaches to an add-on the captured pages mark deprecated in favour of Sana Pay, for which we found no published payment method list, and we found no public information on bundles, tiered pricing, promotions or vouchers. Guest ordering surfaces only as a security caveat about saving cards. 1 3 4
Tax & German legal correctness
Show reasoningHide reasoning
How this is scored
VAT determination, OSS, B2B reverse charge, and the checkout requirements German law actually imposes — judged on what the platform does, not on a plugin someone could buy.
0 — A single VAT rate applied everywhere; no B2B handling, no country logic, no legal-text handling in checkout.
3 — Per-country VAT rates configurable by hand, net prices for B2B possible with effort, and legal texts as free-form pages.
5 — Automatic VAT by destination and customer type, VAT-ID validation with reverse charge, gross and net display per customer group, and the mandatory checkout elements (order button wording, withdrawal policy, price indications) handled.
8 — OSS thresholds tracked and reported, correct invoicing per case including reverse-charge notes, small-business and third-country handling, and e-invoicing (XRechnung/ZUGFeRD) for B2B orders.
10 — Tax and legal correctness are maintained by the vendor rather than the merchant: rates and thresholds updated as the law moves, OSS reporting produced, every invoice case correct out of the box, and documented conformity a lawyer could review.
The Merchant
Tax lives in the ERP: the captured documentation describes Microsoft Dynamics GP tax schedules assigned by hand to items, customers and addresses, while the shop side only controls display — total or detailed, gross or net per customer type, recalculated when the shipping address changes. On VAT-ID validation with reverse charge, OSS thresholds, e-invoicing and the checkout texts German law mandates, I found no public information. 5 6
The B2B Seller
Gross or net presentation can be set per customer type — B2C, B2B and sales agents — with a configurable focus price and a total-excluding-tax toggle, and taxes are recalculated automatically from the ERP's tax schedules when the shipping address changes; the captured tax-engine pages concern Microsoft Dynamics GP. That handles net display for trade customers, but we found no public information on VAT-ID validation, reverse charge, OSS handling, e-invoicing or the German checkout legal texts — the exact cases that decide an EU B2B audit. 5 6
The Developer
The tax engine is the merchant's ERP — Microsoft Dynamics GP schedules do the calculating, with taxes recalculated automatically when the shipping address changes — and cart presentation is configurable per customer type (B2C, B2B, sales agents) including gross/net display and detailed tax lines. We found no public information on VAT-ID validation with reverse charge, OSS, e-invoicing, or the German checkout requirements such as order-button wording and withdrawal policy. Tax maintained through the merchant's ERP configuration is the opposite of rates kept current by the vendor. 5 6
The Operations Lead
Taxes are calculated in the ERP, recalculated automatically when the shipping address changes, and presented per customer type with gross-or-net display and configurable cart presentation — the mechanics exist, but the documented engine sits in the merchant's Microsoft Dynamics GP setup rather than being maintained by the vendor. We found no public information on VAT-ID validation, reverse charge, OSS, e-invoicing, or the German checkout legal texts a lawyer would ask to see. 5 6
The Data Protection Officer
Taxes are configured and calculated in the ERP — the documented mechanism is Microsoft Dynamics GP tax schedules, recalculated automatically when the shipping address changes — and the shopping cart can present gross or net per customer type for B2C, B2B and sales agents. I found no public information on VAT-ID validation, reverse charge, OSS, e-invoicing formats such as XRechnung or ZUGFeRD, or the checkout elements German law imposes like order button wording and withdrawal policy; correctness here rests entirely on the merchant's ERP setup rather than on the platform. 6 5
The Skeptic
Tax presentation is configurable per customer type — gross or net display for B2C, B2B and sales agents, total or detailed lines — and taxes recalculate automatically when the shipping address changes. But the engine the pages document is Microsoft Dynamics GP's sales-tax model, and we found no public information on VAT-ID validation, reverse charge, OSS, e-invoicing or the checkout elements German law requires; correctness here is the merchant's ERP configuration, not something the vendor maintains. 5 6
Extensibility & developer surface
Show reasoningHide reasoning
How this is scored
Themes, apps, APIs and headless — whether the shop can be shaped to the business, and at what cost in lock-in.
0 — Fixed templates, no app ecosystem, no API.
3 — Theme editing within limits and a small app store; a read-mostly API and no local development story.
5 — Custom themes with a template language, an app or plugin ecosystem, a documented REST API, and webhooks for the core order events.
8 — Full storefront API for headless builds, an extension framework with its own lifecycle, staging environments, version control for themes, and documented rate limits.
10 — A platform a team can own: headless-first APIs, open-source or source-available core, plugin architecture with a real dependency model, local development and CI supported, and upgrade paths that do not orphan customisations.
The Merchant
There is an App Center with one-click installs for shipping add-ons, and the return-order system pages are editable in Sana Admin, so some shaping is possible. But on a documented storefront API, webhooks, theme development or staging environments I found no public information — and without an API, every checkout change is a rebuild. 7 8
The B2B Seller
The only extension surface in evidence is the Sana App Center, where delivery apps install with a single click. We found no public information on custom themes or a template language, a documented API, webhooks, staging environments or any headless storefront API, so a buyer cannot see what shaping this shop to their business would cost or what it would lock in. 8
The Developer
There is an App Center (delivery services install with one click) and add-ons with their own lifecycle — Adyen Checkout deprecated in favour of Sana Pay — plus system pages editable inside Sana Admin, which to me is a closed template editor I would eventually have to migrate away from. We found no public information on a theme or template language, version control for themes, a public API, webhooks, staging environments, or local development. The dependency story for extensions shows up only as an uninstall-the-old-one instruction for the Adyen-to-Sana-Pay switch. 4 7 8
The Operations Lead
There is an app store — delivery services install from the Sana App Center with one click, and payment arrives as add-ons — plus editable system pages, selectable page layouts, content elements and single sign-on. We found no public information on a documented API, webhooks, custom themes, staging environments or a local development story, so the cost of shaping the shop beyond the app catalog cannot be judged. 3 4 7 8 9
The Data Protection Officer
The only developer surface in evidence is the App Center, where delivery-service apps install "with a single button click", plus editable system pages for return orders in the admin. I found no public information on theme customisation, APIs, webhooks, a headless storefront, staging environments or any local development story. 8 7
The Skeptic
The only extension surfaces the captured pages show are an app center with one-click installs for shipping carriers and CSV import/export for product pages and shop accounts. We found no public information on an API, webhooks, headless storefront access, theme customisation, staging environments or a local development story. 8 10
Order operations & back office
Show reasoningHide reasoning
How this is scored
What happens after checkout: order management, stock, returns, shipping, and the link to ERP or accounting.
0 — An order list and an email; stock is a number nobody trusts, returns are manual.
3 — Order statuses and basic stock, one shipping integration, and returns handled by hand.
5 — Order workflow with partial shipments, multi-warehouse stock, named carrier integrations with label printing, and a returns process in the system.
8 — Multi-channel order intake, automated fulfilment routing, supplier and dropshipping flows, and maintained interfaces to named ERP and accounting systems.
10 — The shop is the front of an operation: real-time stock across channels and warehouses, returns and refunds fully worked including partials, ERP integration the vendor maintains, and operational reporting a merchant runs the business from.
The Merchant
Returns are properly built — invoice-based and invoice-free flows, reasons pulled from the ERP, file attachments, per-line comments and emails to customer and admin — with real-time carrier integrations for FedEx, UPS, USPS, Purolator and nShift, live order tracking, and stock and prices synced in real time from seven named ERPs. That is beyond standard order handling, though on partial shipments, label printing, multi-channel intake and dropshipping I found no public information. 1 3 7 8
The B2B Seller
Operations are built on maintained interfaces to named ERPs — Dynamics NAV, AX, Business Central and Finance & Operations, SAP Business One, ECC and S/4HANA — with real-time stock, prices and order information synced from the ERP. Returns are properly in the system: invoice-based and invoice-free return orders, reasons and processing driven from the ERP, confirmation and admin notifications, file attachments and line-level comments across four editable system pages. Named carriers come with real-time tracking and location-specific shipping methods, though we found no public information on partial shipments, label printing or multi-channel order intake. 1 7 8 3
The Developer
Returns are worked through properly — invoice-based line-level returns plus invoice-free requests, reasons from the ERP, customer attachments, notifications to customer and administrator — alongside real-time carrier integrations (FedEx, UPS, USPS, Purolator, nShift) with live tracking and location-specific shipping methods. Stock, prices and order information sync in real time with seven named ERP systems, which is the maintained-interface strength of this product. We found no public information on label printing, partial shipments, multi-channel order intake or fulfilment routing. 1 3 7 8
The Operations Lead
This is the ERP shop I want to run: stock, prices and order information sync in real time, seven named ERP systems carry return orders (with SAP Business One on return requests), and returns are genuinely worked — invoice-based line selection, invoice-free returns, ERP-sourced return reasons, RMA notification addresses and customer confirmations. But we found no public information on partial shipments, partial refunds, label printing or multi-channel order intake, so the December-proven back office is not confirmed, and real-time carrier tracking with FedEx, UPS, USPS, Purolator and nShift is the shipping evidence that carries the score. 1 3 7 8
The Data Protection Officer
Returns are genuinely worked — invoice-based and invoice-free return orders with per-line comments, file attachments, ERP-sourced return reasons and administrator notification — and there is real-time integration with named carriers FedEx, UPS, USPS, Purolator and nShift, on an architecture that syncs stock, prices and order information live with seven named ERP systems. I found no public information on label printing, partial shipments, multi-warehouse stock, dropshipping flows or operational reporting a merchant could run the business from. 7 8 1 3
The Skeptic
This is where the product earns its keep: real-time stock, price and order sync with seven named Dynamics and SAP systems, carrier integrations with FedEx, UPS, USPS, Purolator and nShift with real-time tracking, and a fully worked returns process — invoice-based and invoice-free returns, ERP-sourced reasons, file attachments and notification e-mails. We found no public information on partial shipments, label printing, multi-warehouse stock or automated fulfilment routing. 1 3 7 8
Data ownership & exit
Show reasoningHide reasoning
How this is scored
Whether the catalogue, customers and order history remain the merchant's: export completeness, hosting choice, and what leaving actually costs.
0 — Export is a partial CSV; order history and customer records cannot leave intact, and hosting is the vendor's alone.
3 — CSV export of products and customers, order history partial, no self-hosting, no documented migration path.
5 — Complete export of catalogue, customers and orders via API or dump, documented deletion, and a stated data-return commitment.
8 — Full-fidelity export including media and order documents, self-hosting or a choice of hosting partner, and no metering that prices a migration out of reach.
10 — Ownership is structural rather than promised: open-source or source-available platform the merchant can run anywhere, database-level access, documented migration in both directions, and contractual data return.
The Merchant
Leaving is CSV and it is narrow: shop accounts export without passwords, product pages export only the listed custom fields with defaults dropped, new products cannot even be created by import, and the vendor states only data already in the Sana Commerce Cloud database can be exported. On order-history export, self-hosting and a documented migration path I found no public information. 9 10
The B2B Seller
Export is CSV and narrow — shop accounts and product-page content only, with passwords not exported, default values excluded, and the vendor stating that only data stored in the Sana Commerce Cloud database can be exported; we found no public information on order-history export or full-fidelity media export. The structural mitigant is that products, prices, stock and order information live in real time in the merchant's own ERP, so master data is not captive in the platform — but we found no public information on self-hosting, a documented deletion commitment or a migration path. 9 10 1
The Developer
Export is CSV only — shop accounts leave without passwords, product pages without media files (URLs and counts instead) — and only for data stored in the Sana database, so leaving means rebuilding account credentials and re-uploading assets. We found no public information on self-hosting, API-based or full-database export, documented deletion, or a migration path. The ERP-native design keeps master data in the merchant's ERP, which is real ownership, but the shop layer itself exits as partial CSVs. 9 10
The Operations Lead
Export is CSV from Sana Admin only, and only for what the Sana database holds — data in the ERP cannot be exported from the shop side, passwords never leave, default values are dropped, and the product export carries page fields and image counts rather than the media themselves. We found no public information on order history export, self-hosting, or a documented migration path out. 9 10
The Data Protection Officer
Export from the platform is CSV only — shop accounts with the password field left blank, and product pages without default values and without the media files themselves, only counts and URLs — while data that sits in the ERP must be exported from the ERP on the merchant's side, which does mean order history ultimately lives in the merchant's own systems. I found no public information on a documented deletion routine, an API or database-level export, a data-return commitment, self-hosting, or any migration path in either direction; return-order attachments sit on the vendor's web server file system. 9 10 7
The Skeptic
Export is CSV-only and thin: product pages carry just title, URL, description and media counts — default values excluded — and the vendor states plainly that only data already in the Sana Commerce Cloud database can be exported, with data in the ERP to be exported from there; shop accounts export to CSV with passwords left out. We found no public information on order history export, a documented deletion process, self-hosting, or any migration path in either direction. 9 10
European sovereignty
panel opinion
Show reasoningHide reasoning
How this is scored
Where customer and order data live, who the contracting entity is, and which subprocessors sit in the checkout path. Independently sourced by the sovereignty pipeline.
0 — Non-EU vendor and contracting entity, hosting unstated or non-EU, subprocessors unnamed.
3 — EU hosting offered as an option while the contracting entity is non-EU, or the subprocessor list is absent.
5 — EU hosting as standard and an EU contracting entity, but parts of the chain — CDN, analytics, payment routing, support tooling — are non-EU without an explained safeguard.
8 — EU hosting on named infrastructure, EU contracting entity, complete subprocessor list published, any non-EU processing named with its legal basis.
10 — Sovereign end to end and evidenced: vendor, entity, hosting and every subprocessor European, certification published, and a self-hosted option that puts the shop entirely under the merchant's control.
The Merchant
The imprint names Sana Commerce EMEA B.V. in Rotterdam with KvK and VAT numbers, so the contracting side is European. But card processing is outsourced to "validated third-party service providers", and on hosting location, data residency and a published subprocessor list I found no public information — that leaves the checkout chain unverifiable. 1 2 4
The B2B Seller
The imprint names Sana Commerce EMEA B.V. in Rotterdam with a KvK number and a Dutch VAT ID, so the operator side is European. Beyond that we found no public information on where customer and order data are hosted, on the vendor's ownership, or on a subprocessor list — the pages state card processing is outsourced to validated third-party service providers and name Adyen as the payment provider, but the full chain around checkout cannot be reviewed from what is published. 2 4
The Developer
The operator is a Dutch company with a KvK number and NL VAT ID, though the imprint names only the website operator and the contracting entity for the SaaS product could be a different group company. Card processing is outsourced to validated third-party providers sitting in the checkout path. We found no public information on hosting location, ownership, or any subprocessor list, so the residency question a buyer cares about stays open. 2 4
The Operations Lead
The contracting side is European — Sana Commerce EMEA B.V. in Rotterdam with a KvK number and a Dutch VAT ID — and card data never touches the store because processing is outsourced to validated third parties. The captured pages name no hosting location and publish no subprocessor list, so we found no public information on where customer and order data live or who sits in the checkout chain. 2 4
The Data Protection Officer
The imprint names an EU operator in Rotterdam with a KvK number and a Dutch VAT ID, though the captured pages give different company names — the vendor header says Sana Commerce B.V. while the imprint names Sana Commerce EMEA B.V. — and the contracting entity for the cloud product is not stated. I found no public information on where customer and order data are hosted, on any subprocessor list, or on where the CDN and analytics sit, and card processing is described only as "outsourced to validated third-party service providers" with the payment chain naming Adyen and a successor add-on. 2 4 1
The Skeptic
The imprint names a Rotterdam operator with a KvK number and a Dutch VAT ID, but that is the website operator, and we found no public information on the contracting entity for the cloud product, on ownership, or on where customer and order data are hosted. Card processing is outsourced to "validated third-party service providers", and we found no public information naming these subprocessors or their locations. 2 4
Pricing transparency
not rated — the vendor publishes no price
Show reasoningHide reasoning
How this is scored
Whether a merchant can compute the real annual cost — licence, transaction fees, apps, hosting — from public pages alone. The category where the headline price is least often the invoice.
0 — No public prices at all; every tier is a sales conversation.
3 — A monthly headline exists, but transaction fees, mandatory apps or hosting costs are unstated — the invoice is unknowable from the page.
5 — Tier prices public with billing period stated and transaction fees given, but at least one commonly needed piece (a required app, hosting, payment gateway rate) is unpriced.
8 — Every tier priced publicly including transaction or revenue-share rates, order or GMV limits, and the cost of the extensions most shops need; VAT treatment and minimum term stated.
10 — Complete price computability: annual cost derivable for a given order volume and GMV including licence, transaction fees, hosting and typical extensions — and for open-source platforms, an honest statement that the licence is free and where the money actually goes.
The Merchant
On every captured page — homepage, imprint, documentation — I found no public information on licence cost, tiers, transaction fees, revenue share, order limits or minimum term. A merchant cannot begin to compute the annual price; it is a sales conversation. 1
The B2B Seller
Across the captured homepage and documentation we found no public information on licence prices, tiers, transaction fees, hosting costs, billing period, VAT treatment or minimum term. Nothing on these pages lets a merchant compute an annual cost; the price is entirely a sales conversation. 1 2
The Developer
The captured homepage and app pages show no prices at all — no tiers, no transaction fees, no billing terms — and we found no public information on licence cost, implementation cost, or what App Center apps add to the invoice. For a quote-driven B2B platform that is perhaps expected, but the annual cost is not computable from public pages. 1 8
The Operations Lead
Every page we have is marketing or documentation; we found no public information on licence prices, tiers, transaction or revenue-share fees, term lengths, hosting costs, or the price of the App Center and payment add-ons a shop would actually install. The annual cost of running this platform is not computable from anything published here. 1 4 8
The Data Protection Officer
I found no public information on pricing at all: no tier prices, no billing periods, no transaction or revenue-share fees, and no costs for the App Center apps or the payment add-on. The homepage and the help pages name capabilities without attaching a price to any of them, so the real annual cost is a sales conversation, not a computation. 1 8 4
The Skeptic
The captured pages show not a single figure: no licence price, no tiers, no transaction or revenue-share fee, no price for the Sana Pay add-on or the App Center apps, and no contract term or billing period. A buyer cannot compute even a rough annual cost from public information — every element of the invoice is a sales conversation. 1 4 8
European sovereignty — proven facts
1 of 4 dimensions provenBuilt only from facts shown on the vendor's own pages. A dimension we could not prove is left open, not scored as zero.
| Legal entity | Incorporated in NL ⚠ unverified | 3/3 pts | 2 Report an error |
|---|---|---|---|
| Ownership | Not determined | — | uncited Report an error |
| Data residency | Not determined | — | uncited Report an error |
| Subprocessors | Not determined | — | uncited Report an error |
Where this could be wrong
- Evidence ages. The oldest capture behind this page is from 17 Sep 2026. Vendors change pricing and policies without notice; every fact reflects its source as of the capture date shown in the registry.
- Weak sourcing — Legal entity. The imprint names only the website operator; the contracting entity for the SaaS product could be a different group company.
- AI can misread a source. Extraction and judgement are automated; a citation guarantees traceability, not infallibility. If something here is wrong, say so — no account needed, every report is decided within 5 business days, and accepted corrections are published.
What we left out
A claim that does not survive our checks costs us the claim, not the page. This is what was taken off this one.
- We could not confirm any pricing information on the vendor’s own pages as captured, so this page shows none rather than a statement we cannot stand behind. Know more? Tell us
- 1 product fact could not be confirmed on the vendor’s page as captured and was left out of this page and of the panel’s material. Know more? Tell us
Sources (10)
The pages every claim on this page was read from — each one checked, dated, and kept verifiable.
- 1 Vendor homepage www.sana-commerce.com Checked 17 Sep 2026 Details →
- 2 Imprint www.sana-commerce.com Checked 17 Sep 2026 Details →
- 3 Catalogue & checkout — found from sitemap support.sana-commerce.com Checked 1 Oct 2026 Details →
- 4 Catalogue & checkout — found from sitemap help.sana-commerce.com Checked 1 Oct 2026 Details →
- 5 Tax & German legal correctness — found from sitemap support.sana-commerce.com Checked 1 Oct 2026 Details →
- 6 Tax & German legal correctness — found from sitemap help.sana-commerce.com Checked 1 Oct 2026 Details →
- 7 Order operations & back office — found from sitemap support.sana-commerce.com Checked 1 Oct 2026 Details →
- 8 Order operations & back office — found from sitemap support.sana-commerce.com Checked 1 Oct 2026 Details →
- 9 Data ownership & exit — found from sitemap support.sana-commerce.com Checked 1 Oct 2026 Details →
- 10 Data ownership & exit — found from sitemap support.sana-commerce.com Checked 1 Oct 2026 Details →