Use Packages to present what you will deliver, what it costs, and how your client can pay—all in one agreement. Build a reusable offer, let clients choose the services and extras that fit, and connect the accepted work to projects, invoices, payment plans, and recurring billing. Before sending, use the preview to understand what signing will create. After signing, use What this created to find those records.
Start with the part you need
Before you begin
Your workspace needs access to Agreements, and your role must allow you to use them. Collaborator roles do not have access to this area. Opening the resulting projects, invoices, and payment plans also depends on your permissions for those areas.
You do not need a product catalog or a project template to build a package. Enter prices directly in the package. If you want to collect payment inside the agreement, configure your Stripe connection and add the integrated payment block to that agreement. An invoice template controls the resulting invoice's appearance; a Brand Kit controls the package's presentation within its agreement.
Four things with different jobs
Item | What it does |
Package | The complete reusable offer: presentation, offerings, add-ons, payment choices, and project setup. |
Offering | One distinct piece of work inside the package, such as a website build, monthly hosting, or hourly support. Each has its own pricing and project setup. |
Agreement template | The reusable document around the package: your introduction, terms, signatures, forms, scheduling, and optional integrated payment block. |
Project template | A starting structure for delivering the work, including tasks. It is optional; it does not set the price agreed with the client. |
An agreement contains one Package Offer block, but that block can contain several offerings and add-ons. You do not need separate blocks for a website, hosting, and support. Keeping them together lets the client make one coordinated selection and see the resulting payment choices.
Build your first package
Go to Sales → Packages and choose New package.
Start with Presentation. Give the package an internal name, then write the customer-facing title and description. The internal name helps your team find it; it is not a substitute for the title your client sees.
Open Build your package and choose how clients will select offerings.
Add each offering. Use What you will deliver for its title and description, and What you will charge for its billing and price.
Configure What happens internally if the offering should create a project.
Add any Add-ons and Payment Choices, then test the preview before publishing.
The builder keeps the preview beside your settings. Offerings, add-ons, and payment choices can collapse to reduce scrolling. Use their drag handles to change the order your client sees.
Keep the description, price, and delivery outcome together as you build each offering.
Choose the right selection behavior
Behavior | Use it when | Example |
Everything is included | The client is accepting a bundle, not choosing between its parts. The bundle can contain one or several offerings. | A website build plus required monthly hosting. |
Customer chooses one | The offerings are alternatives. You may preselect a default or leave the choice open. | Starter, Business, or Premium website. |
Customer chooses multiple | The client can combine offerings. Set minimum/maximum selections and any defaults. | Website design with optional hosting and hourly support. |
In multiple-choice mode, enable Required offering for the core work the client cannot deselect. Customize that offering's Required button text, such as “Included.” A default is different: it starts selected but remains changeable unless it is required.
For a single non-optional service, use Everything is included with one offering. There is no reason to make the client choose an option when there is no alternative.
Explain the work in your own voice
Descriptions support rich text, lists, images, and paragraph/H1/H2/H3 formatting. Use those heading formats so the agreement's Brand Kit can apply its typography. Cards places offerings alongside one another when space permits; Stacked gives them a vertical arrangement. Check the preview with your actual descriptions rather than choosing a layout based only on the number of offerings.
Customize the choose/selected button wording, each required offering's button text, add-on and payment-choice section titles, total label, price labels, payment-choice descriptions, and installment labels. Write these in the client's language and your own tone. Intentionally blank section titles stay blank. English defaults are starting points, not wording you must keep.
Set what it costs
Billing | How it works |
One time | Unit rate × quantity is charged once. Eligible one-time work can be paid in full or divided into a payment plan. |
Recurring | Unit rate × quantity repeats on its own billing schedule. Recurring work is not divided into a payment plan. |
Hourly | The rate configures an hourly billing project. It is not a fixed total for future work. You can also request an upfront deposit. |
The Price label is the wording beside the displayed amount, such as “per month” or “per hour.” It does not change the billing schedule. Set the actual schedule in the recurring controls.
The Invoice label controls the invoice line's name. Leave it empty to use the offering or add-on's customer-facing title automatically. Use Invoice description for additional invoice detail and Taxable to identify charges that should receive the agreement's tax treatment.
Add optional extras—or required supporting services
Add-ons are useful for enhancements or dependencies: extra pages, logo design, an additional deliverable, or hosting required with a website. Each add-on has one price, which can be one-time or recurring, and its own description and project setup.
Open Add-ons, add an item, and write its customer-facing title and description.
Choose whether it is available for All options or only Specific options. For a dependent service, choose the eligible offerings.
Leave it optional, preselect it with Selected by default, or enable Required when available.
For a simple single charge, use Once per Agreement. Configure its price in What you will charge.
If clients can buy more than one, enable Customer can adjust quantity and set the minimum, maximum, step, and default. Test both the minimum and maximum in preview.
A required add-on is required only when it is available. For example, hosting associated with a website offering becomes included when that offering is chosen; it does not force someone choosing an unrelated service to buy hosting. A selected-by-default optional add-on can still be removed.
For the clearest initial setup, make each add-on billing-only or explicitly configure its own project. Always check the expected outcome before relying on a relationship to another offering's project.
Decide whether the work needs a project
Projects are optional for one-time and recurring work. You can use Packages solely to sell and bill services without adopting project management. Hourly work is the exception: it needs a billing project to hold the agreed hourly rate and support time-based billing.
Expand What happens internally on the offering or add-on.
Choose Create a project and enable Create a project when accepted.
Give it a recognizable project name. Enable Use this project for billing when the offering's billing should be associated with it.
Optionally choose a Project template for tasks.
No project template: Moxie creates a project shell. A designated billing project uses the offering's billing configuration, but no template tasks are created. With a template: Moxie uses its structure and tasks; the agreement's pricing takes precedence over the template's pricing.
Creating a delivery project and using a project for billing are distinct choices. If you configure more than one project for an offering, identify the billing project deliberately. Only selected offerings and applicable selected or required add-ons produce their configured outcomes.
How billing stays connected
One-time work: the invoice lines carry the billing-project relationship. With a payment plan, billing is managed through its scheduled invoices.
Recurring work: a billing project is included in the recurring invoice schedule using Moxie's project-billing integration. If the first period is due at signing, that period is recorded on the initial invoice so the next run does not bill it again.
No billing project: the one-time or recurring amount is represented directly in invoice lines. A project is not required to collect it.
Collect a deposit for hourly work
A deposit is money collected in advance for work that will be billed later. It is not an estimate of total hours, a fixed project fee, or a discount on future work.
Set an offering's billing to Hourly and enter the hourly rate.
Ensure the offering creates an hourly billing project. A project template is optional.
Enable Collect an upfront deposit, enter its amount, and provide a customer/invoice label.
Choose whether the deposit is taxable, then check the amount due today in preview.
When both are configured, the deposit is the prominent upfront amount and the hourly rate remains visible as supporting information. Without a deposit, the rate alone does not create a charge at signing.
The deposit is added in full to the initial invoice. It is not discounted for paying in full and not divided across a payment plan. After payment is recorded and settled, it enters Moxie's deposit ledger for use against future billing through the existing deposit workflow. An unpaid deposit invoice is a request for funds, not available deposit credit.
For example, $150/hour with a $1,000 deposit means $1,000 is requested upfront before any applicable tax. It does not cap the project at $1,000 or automatically bill a number of hours. Record and bill the actual work through the project, applying the deposit through the normal billing process.
Offer Pay in full or a Payment plan
Payment Choices determines how eligible one-time work is paid. The integrated payment block determines whether an amount due at signing is collected inside the agreement. These are separate decisions, so the same package can be reused in agreements with or without integrated payment.
Pay in full and discounts
Add a Pay in full choice, give it a customer-facing label and description, and optionally offer a percentage or fixed-amount discount. The original amount appears smaller and struck through beside the discounted amount.
The discount applies to eligible one-time work, not recurring charges or hourly deposits. This remains true when the first recurring period is due at signing. Tax is calculated on the applicable charges after the one-time discount; non-taxable lines remain non-taxable.
Payment plans
Add a Payment plan choice and define its installments. Enter percentages for the earlier payments; the final payment receives the remaining balance, including any rounding remainder. You can offer more than one plan, but the client chooses one payment choice for the package.
Installments can be due immediately, on a specific date, after a delay from signing, or at a Manual milestone. A manual milestone requires someone to trigger it through the payment plan; merely writing “design approved” does not connect it automatically to task completion. Use clear client-facing labels, such as “At signing,” “Design approval,” and “Before launch,” in the appropriate language.
A plan divides the eligible one-time work and its applicable tax. It does not divide recurring charges or hourly deposits. If the first plan installment is due today, any first recurring periods and deposits due today are added to that first invoice in full, after the installment has been calculated.
Under Invoice settings, choose an invoice template if needed and decide whether invoices should be sent automatically. Without automatic sending, review and send the generated drafts yourself.
Integrated payment versus an invoice sent later
Agreement setup | What the client does | What to expect |
Integrated payment block, with money due today | Completes the required payment as part of agreement completion. | The initial payment must succeed. It is associated with the initial invoice; card fees may change the amount collected when applicable. |
No integrated payment block | Completes the agreement without paying inside it. | Moxie creates the applicable invoice and drafts or sends it according to the configured delivery settings. Signing alone does not mark it paid. |
Nothing due today | Completes the agreement without an upfront payment. | The integrated payment widget is not used to collect money or save a new method at this point. Collection takes place when an invoice becomes payable. |
The amount collected must match the initial invoice, not the whole plan balance. For example, a $2,000 first installment plus $50 for the first hosting period and a $1,000 hourly deposit means $3,050 due today before applicable tax and card fees.
Automatic charging of later invoices requires an available, authorized payment method and the relevant billing setting. Do not assume that sending an invoice or signing a zero-due agreement saves a payment method. Payment-method availability and settlement timing depend on your payment setup.
Recurring billing has its own schedule
For each recurring offering or add-on, choose how often it repeats, any start delay, and an optional end-after-occurrences limit. Enable First period due at signing when the first period should be included in the initial payment. Otherwise, it begins according to its recurring schedule.
Configure recurring invoice delivery and automatic charging separately from the one-time payment choice. Matching recurring schedules can share a recurring invoice schedule; differing cadence, timing, or billing settings can produce separate schedules. Monthly hosting and annual maintenance therefore do not need to be forced into the same cadence.
Paying the website build in full does not pay all future hosting invoices. Likewise, choosing a website payment plan does not split each month's hosting charge into installments.
Tax and card fees
Use the charge's Taxable setting and, for a deposit, its separate taxable setting. The standalone package preview uses workspace tax defaults; a concrete agreement uses its own tax configuration, which can reflect the client. Review the actual agreement before sending.
The selected payment choice shows the pre-tax amount, applicable tax, and total. With a discount, compare the original and discounted pre-tax amounts; the tax is based on the discounted taxable charges. Advanced tax uses the saved tax names rather than replacing them with a generic label. Do not assume that a visible percentage applies to every line.
A price label or description saying “tax included” does not change the calculation. Check the calculated tax and final total rather than relying on wording alone.
The agreement's card-fee policy determines who pays applicable card processing fees. When the client pays the fee, card payment can have a different upfront total from ACH/bank payment. Use the card-specific tokens below if your text discusses that difference; do not add a separate hard-coded surcharge to the package.
Use the preview to understand what will happen
The side-by-side preview shows the client-facing offer. The header's Preview button opens a focused view with an internal Expected outcome panel. That panel answers: “If the client signed with these selections, what would Moxie do?” It is for your team, not a sidebar shown to the client.
Select the offerings and add-ons as a client would. Try required items, optional items, and any quantity limits.
Select each payment choice. Wait for recalculation to finish, then inspect its totals and installment breakdown.
Check Due today separately from Payment choice total.
Review the projects, initial invoice, payment plan, and recurring schedules in What Moxie will do.
Compare Draft and Published versions, and try the intended Brand Kit.
This is a dry run of the processing used for the agreement, not a separate list of guesses. It does not create projects, send invoices, charge a card, or sign anything. A standalone package preview also cannot decide whether a future agreement will contain an integrated payment block; review that final document setting separately.
The customer presentation explains the offer; Expected outcome explains the internal result.
Switching payment choices changes the initial payment and schedule, not the recurring service's agreed cadence.
A worked example
Assume no tax or card fees: a $5,000 website, $50/month hosting with the first period due at signing, and hourly support with a $1,000 deposit. Offer either a 10% pay-in-full discount or a 50/50 payment plan.
Pay in full | 50/50 plan | |
Website | $4,500 after discount | $5,000 across two installments |
Hosting due today | $50 | $50 |
Hourly deposit due today | $1,000 | $1,000 |
Total due today | $5,550 | $3,550: $2,500 + $50 + $1,000 |
Later billing | $50 each subsequent hosting period, plus actual hourly work billed separately | $2,500 final website installment, $50 each subsequent hosting period, and actual hourly work billed separately |
The deposit remains available for the normal deposit-application workflow after it is paid. It is not an additional discount on the website. Future recurring periods and unknown future hours are not included in a lifetime contract total.
Validate and publish
The reusable builder saves draft changes automatically. Saving is not publishing. Validate checks the configuration; Test & publish helps you compare draft and published state. Resolve configuration errors, test the relevant selections, and choose Publish when ready to make the saved package available to agreement templates.
A package can have unpublished changes while an earlier published version remains in use. Confirm which version you are previewing. Publishing changes the version available to linked agreement templates; it does not rewrite agreements already created.
Put the package into an agreement
Open an agreement or agreement template and use Add block → Package offer where the offer belongs.
The block starts as a placeholder. Select a published package in its settings to populate it.
Adjust the block's outer spacing and review it within the document's Brand Kit.
Add the integrated payment block only if payment should be collected inside the agreement.
Add signers, review the complete document, then finalize and share it.
The Quote and Proposal starters include an empty package placeholder; they do not choose a package for you. A draft or agreement template may keep the placeholder while you work. Before finalizing an actual agreement, select a package or remove the empty block.
When there is one client signer, that person is the package decision maker automatically. With multiple client signers, choose who can make the commercial selections and pay. Other signers should not independently change the agreed package.
Understand what stays linked
Where the package is used | What a later global publication does |
Agreement template | The template uses the latest published package when viewed and when creating a new agreement. |
Actual agreement | Its captured package remains unchanged. Later global price or offering changes do not silently change this client's document. |
Agreement-only customization | The edited package belongs to that agreement and is saved there, not published to the global package library. |
In a draft agreement, the package selector lets you switch to a different published package without deleting the block. Its position and spacing remain intact. Use Edit global package to work on the reusable source, or Update from global package to explicitly replace an existing draft snapshot with the latest publication.
Choose Customize for this agreement to open the embedded editor with its preview. Save changes directly to that agreement; there is no separate draft/publish step for this version. Switching packages is disabled once it is customized. Restore from global package discards the agreement-only changes and returns to the published source—review the confirmation carefully.
New workspaces use Package Offers for new selling blocks. Their Add block menu does not include the older Services or standalone Payment Plan blocks. Established workspaces retain those choices. This follows the workspace, so teammates joining an established workspace see the same choices.
Existing agreements and templates that contain legacy Services remain supported, including older templates used in a new workspace. Adding a Package Offer to one asks you to confirm conversion: legacy Services and legacy payment-plan/payment components are removed. The integrated payment block can remain. Conversion does not automatically translate the old offerings into a new package.
After signing: review what actually happened
Open the fully executed agreement in Moxie and review What this created. This is the execution journal: the actual outcome of processing that agreement, not a fresh prediction from today's global package.
Project: open the created work and verify its billing configuration and any template tasks.
Initial invoice: review the first installment or full payment, plus any immediate recurring periods and deposits.
Payment plan: review the remaining installments and their triggers.
Recurring invoice schedule: check the next run, included projects or invoice lines, delivery, and collection settings.
Initial payment: review its processing result when integrated payment was used.
The agreement shows the accepted package selections as locked and retains the accepted payment breakdown. The journal provides links to created records when your role allows access. Those records also show a From agreement link with the originating agreement's captured name and signed date. Invoices generated later by the payment plan or recurring schedule inherit that origin. Older records created before this feature may not have it.
Complete means the configured creation steps finished; it does not mean all future invoices are paid. A draft invoice still needs review/sending, a manual milestone needs to be triggered, and future recurring runs still need ongoing billing oversight.
If processing needs attention
A signed agreement and its operational results have separate states. If a processing step fails, the agreement can remain fully executed while the journal shows Needs attention, with later steps waiting.
Review any records already created, resolve the underlying issue, then use Retry failed steps. Recovery uses the accepted agreement and existing execution records; successful recorded steps are not deliberately recreated. Avoid signing another agreement or manually making replacement billing records simply to work around a failed step, because that can create duplicate obligations. If retries still fail or a payment's status is unclear, contact support with the agreement and related invoice details before attempting another charge.
Use package amounts elsewhere in the agreement
Tokens let your contract text refer to the client's actual selection instead of a typed amount that can become wrong. Insert them through the agreement's token picker or use the exact double-brace syntax below. Write the surrounding sentence in your own language.
These financial values come from the calculated package selection, not the legacy Services block. They update with valid customer selections and payment choices. The authoring canvas can leave financial tokens unresolved before a customer calculation is available; use the package preview to test scenarios and review the client-facing document. Tokens display values—they do not create charges, change a schedule, or configure payment.
The selected payment choice
Token | Meaning |
| The selected payment-choice total after any eligible discount, including tax, immediate recurring periods, and hourly deposits. It includes all one-time installments, not just today's payment. Excludes future recurring periods and card processing fees. |
| The same scope before tax, after the eligible discount. |
| The same scope before both discount and tax. Useful when explaining the pay-in-full comparison. |
| The tax included in the selected payment-choice total, not necessarily the amount of tax due today. |
| The monetary discount on eligible one-time work, not the percentage. Zero when none applies. |
| The amount due at signing including tax, before applicable card processing fees. Same amount as |
| The customer-facing label of the selected payment choice. |
| The agreement currency code, such as USD. |
Do not describe PackageOffer.Total as “everything you will ever pay.” It does not forecast an open-ended subscription or unknown hourly work.
Due at signing and card fees
Token | Meaning |
| The calculated amount due now, including tax: full eligible one-time payment or today's installment, plus immediate recurring periods and deposits. |
| Today's amount before tax, after any applicable discount. |
| The tax on today's charges only. |
| The numeric amount due now, without currency formatting. Prefer the formatted Total token for ordinary contract prose. |
| The calculated client-paid card fee for the upfront payment, if applicable. |
| Today's amount including the applicable client-paid card fee. Use when explicitly describing the card-payment amount, not as a universal bank-payment total. |
One-time and recurring summaries
Token | Meaning in a Package Offer agreement |
| Selected one-time charges before discount and tax. Despite older picker wording referring to add-ons, this includes one-time offerings as well as add-ons. Excludes hourly deposits and recurring charges. |
| Selected one-time charges after the eligible discount, including their tax. It is the whole one-time amount, not just the first installment. |
| Tax on the selected one-time charges after any applicable discount. |
| The sum of the selected recurring schedule amounts before tax. |
| The same combined recurring amount including tax. |
| The combined tax on those recurring amounts. |
| Descriptive details of the agreement's configured taxes. Use amount tokens for the actual calculated tax. |
Mixed cadences need care: $50/month hosting plus $600/year maintenance produces a combined recurring subtotal of $650. That token is neither a monthly total nor an annualized total. Use the package's individual recurring details to explain each schedule. The tokens do not convert cadences or multiply them into a lifetime value.
Because OneTime.Total is before discount and OneTime.TotalWithTax is after discount, do not calculate one from the other by simply adding tax. For a consistent before/after-tax comparison matching the selected payment widget, use the PackageOffer totals.
Example wording
You selected {{PackageOffer.PaymentChoice}}. The amount due at signing is {{UpFront.Total}}. Your selected payment-choice total is {{PackageOffer.Total}}. Future recurring charges and hourly work are billed as described in the package.
If discussing card fees, add a separate sentence such as If paying by card, the amount due at signing is {{UpFront.TotalWithCardProcessingFees}}. Review the wording against your payment configuration and translate it as needed.
The older {{Package.*}} description tokens belong to legacy Services packages; they are not the new Package Offer summary tokens. Use the tokens documented here for the new block.
Troubleshooting
My published price changed, but an existing agreement did not
That agreement has a captured version. In a draft, explicitly update from the global package, switch packages, or customize it. Agreement templates use the latest publication; existing client documents do not silently follow it.
A required item cannot be deselected
Check Required offering or Required when available. If clients should be able to remove it, use an optional item, with a default selection only if desired.
The first payment is larger than the installment percentage
Look for recurring periods due at signing and hourly deposits. Those are added in full, not split. Then check tax and any applicable card fee.
No project or tasks appeared
Confirm the offering was selected and project creation was enabled. A billing-only offer does not need a project. A project without a template intentionally has no template tasks. Check What this created for a failed or waiting step.
The deposit is on an invoice, but not available as credit
Confirm payment has actually been recorded and settled. An unpaid or pending collection is not settled deposit credit. Check the associated hourly project and the deposit ledger before making a manual adjustment.
The package cannot be switched or the agreement cannot be finalized
Switching is disabled for customized agreement-only packages until you restore the global version, and commercial edits require a draft agreement. An empty placeholder must be filled or removed before finalization. Resolve any package configuration and signer errors as well.
The preview is still updating
Wait for recalculation to finish before trusting the latest amounts. If an error appears, check that the draft saved and that the selection is valid. A previous visible amount is not confirmation that the latest configuration was calculated successfully.
Before you send: a short checklist
The intended published package—or agreement-only customization—is in the document.
Required and optional selections, add-on availability, and quantity limits behave correctly.
Every billing project and optional task template is intentional.
Discounts, tax, deposits, initial recurring periods, and installment totals have been checked.
Invoice delivery and recurring collection settings match your process.
The integrated payment block is present only when payment should happen inside the agreement.
Client-facing labels, dates, token wording, and Brand Kit presentation have been reviewed.
Expected outcome matches what you want Moxie to create.
Related articles
Continue exploring Sales