> ## Documentation Index > Fetch the complete documentation index at: https://help.the-meridian.ai/llms.txt > Use this file to discover all available pages before exploring further. # Billing and usage Meridian bills one organization, on one invoice, however many apps it holds: a plan per app, plus any hosting upgrades and runtime add-ons. This page is how that fits together in the product. For what each tier includes, see [Options](/plans-1) and the [comparison](/subscription-2). ## What you're paying for | Layer | Scope | What it sets | | - | - | - | | **Plan** | One app | The tier the app is on (Lite, Pro or Enterprise): its features, baseline allowances, team size and support | | **[Hosting upgrade](/add-ons)** | One app | Bigger hosting limits (Medium or Large): database, bandwidth, instances, and production CPU and memory | | **[Runtime add-ons](/add-ons)** | One app | Capabilities on top of the plan: Redis, Scheduler, object storage, CDN | There's one payer and one bill. The **next invoice** card on the organization shows every active charge (subscription and per-app lines) with the total. A member whose role is limited to some apps sees only those apps' lines, with their prices but no total, and a note saying how many of the organization's apps the role covers. If your organization has no active paid subscription, creating an app on Lite or Pro opens checkout for that app's plan. The app's plan activates once payment is confirmed. This also applies after our team retires an old subscription from an empty organization. Cancelled subscriptions and their billing history are kept. After an empty organization's old subscription is retired, **Create app** opens the app creation form. Members need the `applications.create` permission to use this action. If an existing app has an unpaid retired plan instead, **Choose your plan** opens that app's plan picker. ## Meters and capacity Anything with a ceiling is a meter: emails, automation runs, usage events, Pub/Sub, MCP and SDK requests, keyword tracking, custom fields, segments, discounts, reports, affiliates, bandwidth, database size, instances, logs retention, build history, database backups, scheduler jobs, object storage. Each app's allowances come from **its own plan**. A hosting upgrade **replaces** the plan's database, bandwidth and instance limits with its own, it does not add to them: a Pro app with Medium has 10 GB of database, not 5 + 10. Retention (logs, build history, database backups) always stays with the plan. Each meter shows what's used, what's left, and where the allowance came from. A meter the app has nothing for yet reads **Not included**: object storage and scheduler jobs come only from their add-ons, so an app without them has no allowance to show. Redis and CDN, which have no meter, are listed in the same card: **Active**, **Included with the plan**, the date they end, or **Not included** with an **Activate** button that opens **Add capacity** with that add-on already switched on. Meridian flags a meter that's near its limit or has reached one. At the limit, the action that would exceed it is refused with the limit and your usage rather than silently overrunning. Database and bandwidth work differently, because refusing them would take a live app offline: owners are emailed at 90%, 95% and 100%, and at 100% the app keeps serving but on one instance with the smallest CPU and memory, until it is back under the allowance (bandwidth resets each month) or a larger plan or hosting upgrade raises it. The app's billing page sums this up as **Usage** in its summary card: **Healthy** while every meter is below 80% of its limit, **Near a limit** once at least one reaches 80%, **At a limit** once one reaches 100%, with a link down to the meters concerned. Meters with no limit always count as fine. It is about usage only: an unpaid invoice, the grace period or a suspension never changes it, and they show in their own banners instead. Each meter's button says what raises it, with the same label and the same destination on the app's settings page, its billing page and its Hosting page: * **Add** (emails, storage and other consumption meters) or **Extend** (retention windows), when an add-on sells more of it. It opens the **Add capacity** popup. See [Buying add-ons](#buying-add-ons). * **Upgrade hosting** (instances, database, bandwidth), when only a bigger hosting tier raises it. It opens the [Change hosting](#changing-hosting) page with the smallest tier that raises that meter already selected. Nothing is ever left selected but not applied: every change is confirmed where it starts. ## Back from checkout When you come back from the payment page, Meridian tells you what that checkout did, on the page that fits it: * **Starting to pay for a new organization or app** (onboarding, **Create organization**, **Create app** in an organization that has never paid, **Resume payment**, accepting an Enterprise proposal by card): the app's home, or the organization's page when the checkout covers several apps. * **Paying from a billing screen** (an app's first plan picked on its **Change plan** page, at the end of a free trial for example, or a one-off top-up): back on the billing page the payment started from. * **Saving a card** (updating it from Billing, the payment-failed dialog, the card expiry notice, the suspension screen or a reminder email, or moving from bank transfer to card payments): the organization's **Billing** page. Going back from the payment page without paying lands on the same page, which says the payment was cancelled. After buying a plan, it shows **Payment received, confirming…** and checks the payment with Airwallex, our payment provider, straight away. Once the payment is found, your plan is active and the message says so, usually within seconds. After saving a card (to update it, or to move from bank transfer to card payments), it only says the card is saved: nothing was bought. If a payment was due, updating the card charges it. When an organization's first payment goes through, everyone who can manage its billing (**Billing: Manage**) gets an email saying the subscription is active, with each app and its plan, the renewal date and a link to the invoices. It is sent once per organization: renewals and later purchases do not send it again. An organization billed by bank transfer, or given its plan free, does not get it. If Airwallex is slow to confirm, the organization's **Awaiting payment** banner says the payment was received and keeps checking by itself for a few minutes, instead of offering **Resume payment**. Pressing **Resume payment** later, or picking a plan again, never charges twice: Meridian first checks whether your earlier payment went through, and if it did, it activates your plan from it and opens no new payment page. A payment confirmed late is also picked up in the background within minutes, without anyone coming back to the page. The same goes for a plan bought on a free trial, running or ended: while its payment is confirmed, the trial banner, the app's "trial has ended" screen and its dialog say the payment was received, instead of asking you to choose a plan again. Each payment page pays for what it was opened for, and nothing else. If you open two before paying (a Lite plan for one app, then two Pro apps, say), only the one you pay goes live, and what the other offered is dropped. A plan picked again before paying replaces the earlier pick, unless you pay the earlier page after all, in which case that plan is the one your app runs on. **Resume payment** offers the same lines as the page it replaces, so paying either one activates them. Going back from the payment page with the browser's **Back** button after creating an organization takes you to that organization's page, where **Resume payment** finishes the payment, rather than to a form that would create a second organization. The next **Create organization** starts empty. Confirming a payment needs **Billing: Manage**, like starting one. **Resume payment** pays for every app of the organization at once, so it also needs a role that reaches every app. Members who cannot resume it see that the payment is pending and are asked to get an owner or admin to finish it (see [Permissions](/customer-permissions)). ## Free trial New organizations can start on Lite with a **14-day free trial**. No card is needed: pick Lite at the end of onboarding and your first app runs on Lite right away, with Lite's features and allowances. Nothing is charged during the trial. Whichever plan you pick at the end of onboarding, you land on your first app's home: straight away for the trial, after the payment page for a paid plan. A paid plan opens the app as soon as the payment is confirmed, usually within seconds. The trial is offered once per organization and once per account, and it covers one app. You can add more apps during the trial: each one is a paid subscription, so creating it takes you through checkout, and the first app keeps its free trial until the end. Owners are reminded by email and in the notifications bell a week before the end, three days before, and the day before. If the trial ends without a plan, the app goes offline (its hostname answers with a "not available" page, and its Cloud Run address and pull request previews stop answering), the app's pages show a "Your free trial has ended" notice until a plan is chosen (the organization's own pages stay open, and so do the app's billing and [settings](/app-settings#app-profile) pages), and every feature of the app is closed: its API, SDK, MCP and Pub/Sub traffic is refused, its automations do not run and its emails are not sent. If other apps in the organization are already paid for, only the trial app is closed and the rest keeps running. Everything you built is kept for **30 days** after the trial ends: choosing a plan in that time brings it all back as it was. Owners are reminded two weeks, three days and the day before those 30 days run out. After that, the trial app goes the same way as a [cancelled app](/app-settings#cancelling-an-app): its owners receive an export of its data by email first, then the app, its hosting and everything Meridian stores about it are deleted for good. Your organization's **Billing** page shows the trial in a **Free trial** block: the app on trial, its plan, the days left, the date the trial ends and what happens then. Once the trial has ended without a plan, the block stays and says the app is offline until a plan is chosen. **Choose a plan** opens the trial app's Change plan page. It needs **Billing: Manage** and the trial app within your role's [app scope](/customer-permissions). Other members see the block without it. ## Changing your subscription An app's plan changes on its **Change plan for {app}** page, opened with **Change plan** on the app's billing page or **Change** on the App plan row of its settings Summary: pick a plan, check the summary on the right, then confirm in a dialog before anything is charged. The page opens on the app's current plan, or with nothing selected for an app that has no plan yet. An app on a free trial opens with the plan its trial runs on selected, so the summary shows its price at once. On this page and on Compare plans, the trial banner keeps its days left and end date but hides its **Choose a plan** button. **Compare plans** only shows the plans side by side: choosing one there opens the same page with that plan selected. * **Upgrade** starts immediately. The days left in the current period are prorated and charged to your saved card now. * **Downgrade** is scheduled for your next renewal. You keep your current tier and its higher limits until then, and nothing is charged now. The app's billing page shows the scheduled change and its date, and "Keep" cancels it at no cost as long as the renewal has not happened. In the last 24 hours before that renewal, other plan changes and new apps for the organization wait until it has been billed. * A **first plan for an app** in an organization that already pays joins the existing subscription: it is charged to the saved card, prorated, with no checkout. Only an organization with no subscription yet goes through checkout: once the subscription is live, no new payment page can be opened for it, and every purchase is added to the subscription and charged to the saved card. A checkout for one app's plan brings you back to that app's billing page, which says whether the payment went through and shows the plan as soon as it is confirmed, usually within seconds. * Your **hosting upgrades and runtime add-ons are unaffected** by a plan change. ## Changing hosting Every app runs on the hosting its plan includes, shown as **Included with {plan}** (for example "Included with Pro"), or on a Medium or Large [hosting upgrade](/add-ons). The tier changes on the app's **Change hosting for {app}** page, which works like the plan change: tier cards with their price, their limits and what each changes compared with today, a summary on the right with what is charged today and the app's new monthly total, then a confirm dialog and the result. **Compare all hosting tiers** opens the full comparison table. Every hosting entry point leads there: **Change hosting** on the app's billing page Hosting card, **Change** on the Hosting row of its settings Summary, **Upgrade hosting** on a meter, **Choose** in the hosting comparison, and the upgrade buttons on the app's Hosting page. Changing hosting needs **Billing: Manage**, with the app inside your role's [app scope](/customer-permissions). Hosting size is per app. A **bigger** size is charged immediately, prorated for the rest of the period, and takes over as soon as that payment goes through, usually within a minute. Until then the app keeps its current size, with its limits and its production CPU and memory, and its billing page shows the new size as **waiting for payment**. The unused time on the current size is refunded to your card at the moment of the upgrade, so the charge for the bigger size is what you owe for hosting this period. If that charge fails, the app stays on its current size until it is paid, then moves up, and its hosting can't change again before that. A **smaller** one is scheduled for the next renewal, like a plan downgrade: the app keeps its current size and limits until then, nothing is charged now, and the app's billing page shows the date with a **Keep** button that cancels the switch at no cost. **Going back** to the included hosting removes the upgrade, which takes effect at the end of the billing period you already paid for. Until then the app keeps Medium's or Large's limits, including production's larger CPU and memory. After it, the app runs on the hosting its plan includes. The app's billing page shows the date, and "Keep" undoes the removal before then. ## Buying add-ons **Add capacity** on the app's billing page (or a meter's **Add** or **Extend**) opens one popup that ends the purchase: 1. **Choose** how many of each recurring add-on to add. Redis, Object storage and CDN are activated with a switch rather than bought in units, as an app has at most one of each. When the app already has one, its switch is on and locked, marked **Already active on this app**. Buying one more of them is refused from anywhere else too. **Object storage (per GB)** only adds capacity to Object storage, so it sits inside the Object storage card and opens once the app has Object storage or you activate it in the same popup. The review lists it under Object storage too. An add-on whose removal is pending shows **Keep** in the popup instead of being bought again. Opened from a meter, the add-ons for it come first. The popup also says which hosting the app runs on today, and the size it moves to next: one scheduled for the renewal (for example "Hosting today: Large (changes to Medium on Nov 3, 2026)"), or a bigger one waiting for its payment ("Hosting today: Medium (Large once its payment goes through)"), with a link to change it: hosting tiers are not sold in this popup. 2. **Review** each line with its monthly price, what is charged today (prorated to the renewal), and the app's new monthly total. 3. **Confirm and pay** applies everything chosen in one charge to the saved card, then shows the amount. If our payment provider has not finalized the invoice yet, the result says the card was charged and that the exact amount appears on your invoices shortly. It only says nothing was charged when nothing was. An add-on starts working once its charge is paid, usually within a minute. The confirmation after **Confirm and pay** follows it while it stays open: confirming the payment, then the new capacity active, or, if the card declines the charge, the amount still owed with a **Pay now** button. On the app's billing page the add-on shows as **Confirming** until then, and as **Waiting for payment** if the charge failed. It does nothing in the meantime and starts as soon as what is owed is paid. More units of an add-on the app already has wait the same way: the app keeps the units it has, the new ones show as their own line, **Confirming**, and they join the add-on once their charge is paid. If our payment provider refuses a change (it refuses every change while a renewal payment is unpaid, for example), nothing is added and nothing is charged: the app keeps exactly what it had. The same holds for a plan, a hosting size and **Keep** on a removal. Billing changes for an organization go through one at a time. A change made while another is still going through, from another tab or by a teammate, waits a few seconds for it, and is refused with a message to try again if the first takes longer. One-time top-ups are not in the popup: **Buy** on a top-up takes you straight to its own checkout. ## Removing add-ons **Remove** on an add-on opens one confirm dialog: choose how many of its units go, then confirm. Removing an add-on, or some of its units (for example 2 of 3 GB of object storage), follows the same rule as a plan downgrade: it takes effect at your next renewal, and nothing is refunded. That holds even for an add-on bought the same day. The app keeps their capacity until the renewal date, and the renewal invoice no longer bills them. Until then the add-on stays on the app's billing page with the date its units end (for example "2 of 3 end on Oct 13, 2026"), and the organization's **Billing** page shows the same date on the add-on's line of the next invoice. **Keep**, on either page, puts the units back at no cost. When several units are ending, it asks how many to keep, and the others still end on that date. Buying units of an add-on whose removal is pending takes the removed units back first, at no charge, and only the units beyond them are new purchases. Removing and keeping add-ons needs **Billing: Manage**, with the add-on's app inside your role's [app scope](/customer-permissions). Removing Redis, Scheduler, Object storage or CDN also deletes the add-on itself on that date, in every environment of the app, with the data it holds: one line on the billing page pays for that add-on in all of the app's environments, so the app keeps none of them once the line ends. Cancelling it from its card in **Hosting** does the same. An add-on the app's plan already includes is kept. On the app's billing page, the extra GB (**Object storage (per GB)**) are shown inside the Object storage line. Removing Object storage also ends them on the same date, as they have no bucket to add to once it is gone, and the remove dialog says so. Keeping Object storage does not keep them: keep them on their own afterwards. Their **Keep** stays unavailable while Object storage is ending. While a renewal payment is unpaid there is no paid period left to run out, so a removal applies at once. Redis, Scheduler, Object storage and CDN are the exception: removing one, from the billing page or from **Hosting**, is refused until the payment method is updated, the same as [cancelling an app](/app-settings#cancelling-an-app), so the add-on and its data stay as they are. ### The last 24 hours before a renewal Removals, Keep, smaller hosting sizes and app cancellations are passed to the payment provider 24 hours before the renewal, so the renewal bills only what renews. A change made in those 24 hours still takes effect at that renewal. Units of an add-on bought in that window, on an add-on that was removed or kept this period, work at once and are billed from the renewal. Hosting upgrades and app plans changed in the window follow the same rule. ## Cancelling Cancelling an app also takes effect at the end of the paid period, and nothing is refunded for the days left. The app keeps running until then, every one of its lines (plan, hosting upgrade, runtime add-ons) stops renewing right away, and **Keep the app** undoes it at no cost before the date. A smaller plan or hosting size scheduled for the renewal is set aside with the cancellation, and **Keep the app** schedules it again. Until then the app's plan and hosting cannot be changed, nothing can be bought for it, and its hosting upgrade and add-ons are not kept one by one: **Keep the app** renews them together. On that date, Meridian builds an export of the app's data first (the same zip as the organization's [data export](/organizations#exporting-your-data), scoped to the app: a fresh dump of each of its databases, its CRM as CSV files and its configuration as JSON) and emails the organization's owners a link to it. Only once that export is safe does Meridian release the app's hosting and delete the app for good, everything it stored about the app included. The export stays downloadable for 90 days. See [Cancelling an app](/app-settings#cancelling-an-app). Every app is cancelled on its own, from its settings, by someone with **Applications: Delete** who confirms with the code Meridian emails them. Billing actions never cancel an app: removing an app's plan from the billing pages is refused and points to the app's settings, and there is no action that cancels every app at once. To close everything, [delete the organization](/organizations). An app with nothing paid for to run out (no plan, or a free trial) is deleted right away, after the same export. While a renewal payment is unpaid, or the organization is suspended for it, nothing can be cancelled until the payment goes through. ## Your card While your organization pays by card, its **Billing** page shows the card on file in a **Payment method** block: its brand, its last 4 digits and its expiry date. That card is charged at every renewal, for anything bought mid-cycle (a plan upgrade, a first plan for another app, a hosting upgrade or an add-on) and for the retries of a failed payment. To replace it, with a new company card or after losing one, choose **Update card**. It opens our payment provider's secure page, where you enter the new card, and from then on every payment is charged to it. Updating the card charges nothing by itself. If a payment is unpaid, the new card pays it at once. See [When a payment fails](#when-a-payment-fails). The block shows the new card once our payment provider has confirmed it, usually within a few seconds. **Update card** needs **Billing: Manage**. Members with **Billing: View** see the card but cannot change it (see [Permissions](/customer-permissions)). The card pays for every app of the organization, so the block only shows to members whose role reaches every app. The same goes for **Update card** and **Pay now** on the card expiry notice, the payment-failed notice and the suspension screen: a member whose role is limited to some apps is asked to get an owner or admin to do it. When the card expires within 30 days, the block marks it **Expires soon**, and **Expired** once the date has passed. Update it before then so the next renewal goes through. Members with **Billing: Manage** whose role reaches every app also see a notice about it on each app's billing page. The block only appears while a card is being charged. During a free trial or after it ends without a plan, while the first checkout is unfinished, after the subscription is cancelled, when you are billed by invoice, and on a partnership plan, no card is charged, so there is none to show or update. A trial needs no card: you enter one at the checkout for your first plan. ## When a payment fails If the card on file cannot be charged at renewal, nothing changes for your apps at first. Airwallex, our payment provider, keeps retrying the card, and you have a **30-day grace period** to sort it out: every app stays online and every feature keeps working. * **During the grace period.** Owners get an email the day the charge fails, then on days 1, 2, 3, 7, 14, 21, 27 and 29, and every member sees a notice in the app until it is fixed. Each email carries the amount due, a link to the unpaid invoice and a button to update the card. Updating the card, or paying the invoice from its page, charges what is owed at once and ends it. If a retry succeeds on its own, the reminders simply stop. * **Several unpaid invoices.** Two failed charges in a row (a renewal and a hosting upgrade, for example) leave two unpaid invoices, and the organization stays unpaid until both are settled. The amount due is their total. Updating the card pays every one of them, oldest first. **Pay now** opens the oldest, and the next one takes its place once it is paid. * **A declined plan change still applies.** A plan change takes effect at once, even when the card declines its charge. The confirmation then says so with the amount still owed and a **Pay now** button. Once you close it, the payment-failed notice takes over, and the amount joins the grace period like any failed charge. * **A declined add-on or hosting upgrade waits for the payment.** An add-on or a bigger hosting size starts only once its own charge is paid: the add-on stays inactive, and the app keeps the hosting size it had. The confirmation follows the charge while it is open, from confirming to active, or to the amount still owed with a **Pay now** button when the card declines it. The payment-failed notice lists what waits under **Waiting for this payment**. A plan bought for a new app works at once either way. * **What is due, not the face value.** When a change replaces a line whose charge failed, the unused time is credited to that unpaid invoice before it is paid, so it can owe far less than its total (a $75.60 invoice can owe $0.02). Every amount you are asked to pay, in the app and in the emails, is what is still due. * **Removing a line does not settle it.** Removing an add-on or a hosting upgrade while a payment is unpaid takes effect, but what is owed stays owed, including the charge for that line if it was the one that failed. The organization stays in its grace period until the invoice is paid. If you think a charge should be cancelled, contact us. * **After the grace period.** Your apps keep running, but the organization can now be suspended. Nothing suspends automatically: the Meridian team looks at each case, and may reach out to you first. * **While suspended.** Every app of the organization goes offline. Its address shows a "not available" page, its Cloud Run address and its pull request previews stop answering, its dashboard pages show a **Pay now** screen, and its API, SDK, MCP and Pub/Sub traffic is refused. Shopify webhooks are held and delivered once you pay (a webhook still held after 30 days is discarded), except Shopify's privacy webhooks (customer data requests and redactions), which keep reaching your apps. Billing stays open, so you can [update the card](#your-card) and pay the invoice, and so does the organization's [data export](/organizations#exporting-your-data). Plans, apps and add-ons cannot be changed, and nothing can be cancelled, until the payment goes through. Owners get an email when the suspension starts. * **Paying lifts it at once.** As soon as the payment goes through, the suspension ends and every app comes back online exactly as it was. Enterprise customers who pay by bank transfer are never suspended. See [Enterprise](#enterprise). ### If nothing is paid A suspended organization's data is kept for **60 days** after the suspension, then deleted. | After the suspension | What happens | | - | - | | Day 30 | Owners are emailed the date everything will be deleted, with a fresh export of the organization's data to download. | | Day 50 | A last warning, with a new export. | | Day 59 | A final copy of every database is taken ahead of the deletion. | | Day 60 | Every app goes the same way as a [cancelled app](/app-settings#cancelling-an-app): its owners receive an export of its data by email first, downloadable for 90 days, then the app, its hosting and everything Meridian stores about it are deleted for good. The subscription is closed so nothing more is billed, and owners get an email confirming the deletion. | Paying at any point before day 60 lifts the suspension, and nothing is deleted. After the deletion the organization itself, its members and its billing history remain, and you can create a new app by choosing a plan for it. ## Enterprise An Enterprise plan is priced for one organization, app by app, around what you actually need. It starts from everything in Pro and adds to it: higher or no ceilings on the meters, capabilities Pro does not include such as single sign-on, audit logs and the [always-on server](/always-on-server), and hosting add-ons bundled in rather than bought separately. Once it is set up, it behaves like any other plan in the product, and the app's billing page shows what it includes. You can pay for it by card, like every other plan, or **by bank transfer**. On bank transfer we issue an invoice each cycle with agreed payment terms, usually 30 days, and nothing is charged automatically. Your organization's billing page shows what is currently owed and when it is due, with the invoice to download, and we email the same to your owners when an invoice is issued and as its due date approaches. Quote the invoice number on the transfer so we can match it. Nothing about your apps changes while an invoice is outstanding: a late bank transfer is a conversation, not an interruption. To start one, [talk to us](/subscription-2). **Starting on Enterprise.** After a conversation with us, we send you a link. It works once and is not tied to an email address: open it, create your account or sign in, and an organization named after your company is created for you. A new account confirms its email address first: we send a link to the address you entered, and once you open it and sign in you land in the organization to set up your apps. The link never reopens an account that was closed; if your address belonged to one, use another address or ask us to reopen it. There is no plan to pick, no free trial and no card to enter. You set up the apps you want on Meridian, and our team prices each one from the conversation we have with you. While we do, the organization is in setup only: you can connect Shopify, install the SDK and adjust settings, but hosted deploys and email sends wait until the plan is in place. When it is ready you get an email and a notice in the app; on card you accept the whole proposal in one step from your organization's billing page, and on bank transfer the plan is already in place. Each negotiated plan is priced for one app and applies to that app only. It is accepted from the proposal, never picked on a **Change plan** page, and it cannot be moved onto another app or used to create one. An app you add later waits, in setup only, for the price our team sets for it. If your organization has not given its billing details yet, our team confirms them with you when we set up the plan: the country decides the VAT, and an Israeli business's company name and VAT number go on the first invoice, which bank transfer issues as soon as the plan is in place. You can change it later on your organization's Details page. When an Enterprise plan is first set up for one of your apps, your app's billing page shows it with the agreed price and asks you to accept it. Nothing changes until you do. If you later renegotiate, the new capabilities and limits apply straight away, and the new price normally starts on your next invoice; if we agree to bring it forward, the difference for the rest of the month is invoiced separately and we tell you before publishing. **Partnership plans.** For a partner, our team can set up the Enterprise plan free of charge. Nothing is billed and no invoice is issued: the organization's billing page lists each app as included, with no renewal date and no card. If the organization paid for a plan before, that subscription ends when the partnership plan is in place, and nothing is lost: the plan starts from everything your apps had, including hosting size, staging environments, backup retention and the AI assistant. Add-ons, top-ups and hosting changes are not bought on a partnership plan. Everything it includes is set up by our team, so get in touch to change it. ## VAT and billing details Prices are in USD and exclude VAT. Meridian is an Israeli company (MERIDIAN AUTOMATION LTD, Israeli VAT number 517360293), registered for VAT in Israel only, so your **billing country** is all that decides the VAT on your invoices: | Billing country | VAT on your invoices | | - | - | | Israel | Israeli VAT (18%), added on top of every price | | Any other country | None. Services exported from Israel are zero-rated, and each invoice says so | Meridian does not charge EU VAT, UK VAT or US sales tax. You give the billing country when you create the organization: it is a required field of **Create organization** and of the plan step of onboarding, because the VAT is set on the subscription when it starts. The country, and an Israeli business's company name and VAT number, are shown and edited on the organization's **Details** page, under its name, with the VAT they decide. An organization created before billing details existed is asked for its country at its next checkout, before the payment page. An Israeli business can also give its company name and Israeli VAT number, and its tax invoices are made out to them. The VAT number is checked as you type: a number that is not a valid nine-digit Israeli VAT number is flagged as soon as it has nine digits, or when you leave the field. Anyone with **Billing: View** can read the billing details. Changing them needs **Billing: Manage** and, because they decide the VAT on every app's invoices, a role that reaches every app: a member whose role is limited to some apps sees them read-only. When the organization has no billing country yet, that member can still give it when paying for one of their apps, but cannot change it afterwards (see [Permissions](/customer-permissions)). Changing the billing country changes the VAT on invoices issued from then on, and the same goes for the company name and VAT number: an invoice is made out to the details it was issued with. Invoices already issued keep their VAT and their buyer, and a refund or credit follows the invoice it comes from: if you move to Israel mid-month and then upgrade, the unused part of the old plan is credited at 0% and the new charge is invoiced with Israeli VAT. Where an amount includes VAT, Meridian shows it: the **next invoice** card adds it under the total, the confirmation after an upgrade lists it on its own row, and the invoice history shows the VAT inside each invoice. Every invoice carries Meridian's legal name, Israeli VAT number and registered address. ## Invoices Every issued invoice is listed with its number, date, amount and status, separated into subscription and one-off charges, and downloadable as a PDF. Invoices appear after your first charge, at the start of each billing cycle. One invoice covers every app of the organization and cannot be split per app, so reading invoices needs **Billing: View** and a role that reaches every app. A member whose role is limited to some apps gets no **Invoices** button and no receipt link after a purchase. An invoice is: * **Paid**: the card was charged. * **Processing**: issued, and the automatic charge has not been tried yet. Nothing to do. * **Payment failed**: the card was declined. The invoice waits for the next retry, or for you: members with **Billing: Manage** get a **Pay now** button on its row, which opens its payment page. See [When a payment fails](#when-a-payment-fails). * **Void**: cancelled, nothing to pay. An unpaid invoice also shows what is still due on it when a credit lowered it, and a paid one shows any credit it received before payment ("\$75.58 credited before payment"). Credit notes are listed next to the invoices they came off. A credit note is **Refunded** when it gave money back to your card for unused time (**Refund pending** until the refund settles), or **Credited** when it lowered an invoice that was not paid yet, so nothing was refunded. The totals at the top cover the current year: **Charged this year** is what your card actually paid (an invoice credited before payment counts for what was left to pay), **Refunded this year** is what came back to the card, and **Net cost this year** is the difference. If our payment provider cannot return the credit notes when you open the page, a notice says so, the refunds still appear under each invoice, and the totals count them from there. Subscription PDFs use descriptive line names, such as **Meridian Pro subscription** and **Medium hosting**, with the service dates beneath recurring lines. The invoice memo lists your organization's applications. Apps on the same price share one line with their combined quantity. Bank-transfer invoices also include your payment terms and transfer instructions. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.