Lesson

How DocVision Converts PDF Purchase Orders into Acumatica Sales Orders

How DocVision Converts PDF Purchase Orders into Acumatica Sales Orders

DocVision turns a customer's PDF purchase order into an Acumatica sales order without anyone retyping a line. That sounds simple, but the data flow behind it has a clear shape worth understanding: a PDF is imported and becomes a reusable template, the template maps every PDF field to an Acumatica field, cross-references resolve the customer and the items, a review screen shows in color whether the document is ready, and only then is the sales order generated. Knowing which stage a document has reached, and which field controls the next step, is what makes PDF automation dependable rather than unpredictable.

The Biz-Tech Services DocVision product is a PDF scan and import enhancement built natively for Acumatica ERP. Users upload PDF files such as purchase orders or shipping requests and generate the corresponding sales orders inside Acumatica, eliminating manual data entry. This article follows a PDF through the entire flow, from the initial setup and template creation to the generated sales order, and identifies the fields users should monitor at each point.

What DocVision Does in Acumatica

DocVision is an Acumatica ERP enhancement that automates the creation of sales orders from PDF documents. It reads an uploaded PDF, identifies the customer and ship-to information using pre-configured templates, maps the document's values to Acumatica fields, and generates a sales order from the result. Because parsing rules are defined per customer, the same system can handle many different document formats and structures, which matters when every customer sends purchase orders in their own layout.

Several characteristics shape how the product behaves in practice. It is built natively for Acumatica, so it runs without external dependencies and works within Acumatica's secure environment, respecting user permissions and audit trails. It reduces data entry mistakes by extracting information directly from the source document, and it standardizes incoming sales data regardless of the style of the originating document. For high-volume sales operations, that combination of speed and consistency is the point of the product.

The DocVision Data Flow at a Glance

Before looking at individual screens, here is the path a PDF travels to become a sales order:

• Azure setup establishes and tests the credentials that allow customer purchase order PDF files to be brought in and processed.
• On the PDF Import Settings screen, a PDF is imported and a template is created, defining the mapping between PDF values and Acumatica values.
• The system automatically populates PDF FieldName, PDF Value, and the Target Object and Source Field mappings, which can then be adjusted manually.
• Inventory and customer cross-references resolve the PDF's item and customer values to real Acumatica inventory IDs, customers, and locations.
• On the Import Documents screen, each document is reviewed, with green, red, and yellow indicating readiness, errors, and mapping warnings.
• Generate Sales Order creates the order, sets the Generated checkbox, and records the order number and order type against the document.
• The Import PDF Documents inquiry and the batch generation screen provide oversight across many documents at once.

Each field discussed below sits at one of those handoffs.

Stage One: Azure Setup and Testing Credentials

Setting up Azure in Acumatica allows the ERP system to run on Microsoft's cloud platform using services such as Azure SQL Database, Virtual Machines, and Storage. Beyond the general benefits of scalability, security, performance, backups, disaster recovery, and Single Sign-On through Azure Active Directory, this configuration is what supports importing customer purchase order PDF files so they can be processed and converted into sales orders within Acumatica.

One control on this screen deserves to be used before anything else is attempted. The Test Credentials button confirms that the setup credentials are configured correctly. Running it early is the cheapest way to separate a credential problem from a mapping problem later, and it should be the first checkpoint whenever documents stop arriving.

Stage Two: Building a PDF Template in PDF Import Settings

PDF Import Settings is where the intelligence of the product lives. Pressing the plus button opens a new workspace that allows a PDF file to be imported and a template created from it. Once the PDF is imported, the screen defines the mapping between PDF values and Acumatica values, and that mapping is what every future document of the same format will reuse.

Reading the automatic mappings

After a PDF is imported, the right side of the screen displays the file itself, with the ability to move to the next or previous page and to zoom in and out, so the source document can be read while mapping. The system automatically sets the PDF FieldName and PDF Value entries, and on the Import Mappings tab it also automatically sets the mappings between Target Object and Source Field values. From there it is possible to manually map all PDF fields to the corresponding Acumatica values, correcting or extending what was detected automatically.

Header versus detail mapping: the Target Object rule

One rule governs whether a mapped value lands on the order header or on an order line, and getting it wrong is a common early mistake. To map header fields of a sales order, select Sales Order and then Advanced in the Target Object. To map details on the Sales Order screen, select Sales Order, then Details, then Advanced. The presence or absence of Details in that path is the entire difference between a value appearing once on the order and appearing on each line.

The Active checkbox decides what actually gets written

During sales order generation, only the fields for which the Active checkbox is selected will be uploaded. This is the single most important field to check when a mapped value fails to appear on a generated order. The mapping can be entirely correct and still produce nothing if Active was never selected, which makes this checkbox the first place to look rather than the last.

Handling PDFs that have no purchase order number

Not every incoming document carries a purchase order number, and DocVision handles that case explicitly. Under the Description section there is a Dynamic PO Number field. If there is no purchase order number in the PDF file, this checkbox is automatically selected during the file import process and a warning is displayed reading that the document for the mapping does not have any number and asking you to select an alternative purchase order number.

After that warning appears, a Release PO Number field becomes available, which allows the values of the header to be mapped to existing values of the field. In other words, the system does not simply reject a document without a number; it asks you to nominate which header value should serve as the number instead.

Inventory and customer cross-references

Two cross-reference layers translate the PDF's vocabulary into Acumatica's. Enabling CrossRef for the Inventory ID field makes the Inventory Cross-Reference tab appear, where PDF items can be mapped manually to Acumatica inventory IDs, or where all items can be imported at once via Excel. The Excel route matters for onboarding a customer with a long catalog, since mapping item by item does not scale.

When Cross Reference is selected, the Customer Cross-Reference tab appears, allowing PDF customer values and locations to be mapped to Acumatica customers and locations. This is the mechanism behind the product's customer recognition: the template knows that a particular string in a particular position identifies a specific Acumatica customer and ship-to location.

Stage Three: Reviewing Documents on the Import Documents Screen

The Import Documents screen is the review and correction stage. It allows changes to be made to existing or previously imported documents, and it also enables documents to be imported directly from this screen. Selecting a document number displays the PDF already imported through PDF Import Settings along with all mappings for that document, and it retains the Template ID information, so you can always see which template produced a given result.

The green, red, and yellow color code

Three colors communicate document readiness at a glance, and teaching users to read them saves a great deal of investigation:

• Green indicates that everything is mapped correctly and the file is ready for generating a sales order.
• Red indicates that an item line hit an issue during the import process; the line turns red and an error message is displayed in the Error Message field.
• Yellow indicates a mapping problem, for example items that are not mapped correctly.

The distinction between red and yellow is worth stressing. Red points to a specific failure with a message attached, so the Error Message field tells you what happened. Yellow is a warning that the document is not yet ready, most often because item mapping is incomplete.

Resolving yellow warnings with Validate Items

Yellow warnings are addressed with the Validate Items button. It maps all PDF items to their Acumatica values and displays them on the Details tab, provided those items are already mapped in the Inventory Cross Reference on the PDF Import Settings screen. That proviso is the key to using it well: Validate Items applies existing cross-references, it does not invent them. If an item has never been cross-referenced, validation cannot resolve it and the cross-reference must be created first. The button can be used frequently when PDFs are imported from the same screen.

Stage Four: Generating the Sales Order

On the Documents tab, the Template ID, document number, Order Type, and Customer are displayed, which together confirm that the right template and the right customer were matched before anything is created. Once setup is complete, opening the three dots menu and selecting Generate Sales Order creates a sales order from all the mapped data.

Three results confirm success, and users should check all of them. The order number and order type are displayed against the document, the Generated checkbox is automatically selected, and the document number becomes visible on the Sales Order screen itself. That last item is the important one for traceability, because it means anyone looking at the resulting sales order can see which imported document produced it.

Batch Processing and the Import PDF Documents Inquiry

Two features exist for working across many documents rather than one at a time. A generic inquiry has been created where all document numbers, Template IDs, customer information, and document generation dates can be found, with hyperlinks on those fields that lead directly to the Import Document screen. This is the natural starting point for a daily review, since it answers what came in, under which template, for which customer, and when.

For processing volume, the Generating Sales Orders screen has been modified to allow orders to be imported in batches and sales orders generated from them. The Document Number field can be used to filter by document number and generate the corresponding sales order, which makes it practical to work through a queue of documents rather than opening each one individually.

Where to Monitor DocVision Results in Acumatica

When configuring templates, training users, or investigating a PDF that did not produce the expected order, these are the fields and screens that show what actually happened:

• The Active checkbox on each mapping, since only fields with it selected are uploaded during sales order generation.
• The Target Object path, where Sales Order then Advanced maps a header field and Sales Order then Details then Advanced maps a line field.
• The Dynamic PO Number checkbox and the Release PO Number field, which together handle documents that arrive without a purchase order number.
• The Inventory Cross-Reference tab, which resolves PDF items to Acumatica inventory IDs and can be loaded in bulk from Excel.
• The Customer Cross-Reference tab, which maps PDF customer values and locations to Acumatica customers and locations.
• The color of each line on the Import Documents screen, where green means ready, red means a line-level error, and yellow means a mapping warning.
• The Error Message field on any red line, which carries the specific reason the line failed.
• The Template ID retained against each document, which identifies which template produced the mapping.
• The Generated checkbox, order number, and order type on the Documents tab, which confirm the sales order was created.
• The document number displayed on the Sales Order screen, which links the finished order back to its source PDF.
• The Import PDF Documents generic inquiry, for document numbers, Template IDs, customer information, and generation dates across all documents.

DocVision for Acumatica: Frequently Asked Questions

What is DocVision for Acumatica?

DocVision is a Biz-Tech Services enhancement for Acumatica ERP that automates the creation of sales orders from PDF documents. Users upload PDFs such as purchase orders or shipping requests, and DocVision extracts the data using pre-configured per-customer templates and generates the corresponding sales order in Acumatica, removing the manual data entry step.

How does DocVision know which customer a PDF belongs to?

Through the Customer Cross-Reference tab, which appears when Cross Reference is selected. It maps PDF customer values and locations to Acumatica customers and locations, so the system can identify customer and ship-to information from each PDF using the pre-configured template. Because parsing rules are defined per customer, different customers can send completely different document layouts.

What do the green, red, and yellow colors mean on the Import Documents screen?

Green means everything is mapped correctly and the file is ready for sales order generation. Red means an item line encountered an issue during import, with the reason shown in the Error Message field. Yellow means a mapping problem, typically items that are not mapped correctly, which the Validate Items button can often resolve.

What happens if a PDF has no purchase order number?

The Dynamic PO Number checkbox under the Description section is automatically selected during import and a warning appears stating that the document for the mapping does not have any number and asking you to select an alternative. The Release PO Number field then becomes available, letting you map header values to existing values of the field so the document still receives a usable number.

Why is a mapped field missing from the generated sales order?

Check the Active checkbox on that mapping first. During sales order generation only fields with Active selected are uploaded, so a correct mapping with Active cleared produces nothing. If Active is set, verify the Target Object path, since header fields require Sales Order then Advanced while line fields require Sales Order then Details then Advanced.

How do you map PDF line items to Acumatica inventory IDs?

Enable CrossRef for the Inventory ID field, which makes the Inventory Cross-Reference tab appear. From there, PDF items can be mapped manually to Acumatica inventory IDs, or all items can be imported at once through Excel. Once those cross-references exist, the Validate Items button on the Import Documents screen will apply them and populate the Details tab.

Can DocVision generate sales orders in batches?

Yes. The Generating Sales Orders screen supports importing orders in batches and generating sales orders from them, and the Document Number field can be used to filter by document number and generate the corresponding order. The Import PDF Documents generic inquiry gives an overview of all documents, with hyperlinks back to the Import Document screen.

Work With the Biz-Tech Services DocVision Product

DocVision is straightforward once the flow is clear. Azure setup and tested credentials open the door, PDF Import Settings turns a sample document into a reusable per-customer template, the Active checkbox and the Target Object path decide what is written and where, inventory and customer cross-references translate the document into Acumatica's own identifiers, the Import Documents screen shows readiness in color, and Generate Sales Order completes the journey with the document number visible on the finished order. Teams that know which field governs each handoff can turn a stack of customer PDFs into accurate sales orders quickly and consistently.

If your business receives customer purchase orders as PDFs and wants them turned into Acumatica sales orders without manual re-keying, we are glad to help you scope, configure, and roll out DocVision. Visit https://biz-techservices.com to learn more about our Acumatica expertise or to schedule a personalized demonstration of the Biz-Tech Services DocVision product.

---

by Gary

How CRV Lines Flow Through Sales Orders, Shipments, and Invoices in Acumatica

How CRV Lines Flow Through Sales Orders, Shipments, and Invoices in Acumatica

California Redemption Value, or CRV, has to appear on the invoice as its own line, and it has to stay attached to the product that generated it. That is the whole problem CRV processing in Acumatica solves. When a beverage item is added to a sales order, the system automatically creates a second line for its associated CRV item, carries the same quantity and warehouse across, and keeps the two lines linked by parent and child references all the way through shipments and invoices. Understanding where that child line comes from, which fields control whether it appears, and how the link survives downstream is what keeps CRV billing accurate.

The Biz-Tech Services CRV solution for Acumatica handles this automatically rather than asking order entry staff to remember an extra line on every beverage order. This article follows a CRV line through the full Acumatica data flow, from the item configuration that defines it to the invoice where it is billed, and identifies the fields users should monitor at each stage.

What a CRV Item Is in Acumatica

A CRV item in Acumatica is a non-stock item used across the inventory and sales modules to identify products that carry an environmental fee. It is automatically added to sales transactions when you sell beverages that fall under California's recycling program. The distinction that matters most is structural: CRV items are only ever non-stock items. They represent a fee rather than physical goods, so they must never be set up as stock items, and the configuration will not behave correctly if they are.

In practice this means every beverage product you sell has two records behind it. The parent item is the actual product being shipped, and the child CRV item is the environmental fee attached to that product. Acumatica keeps them associated so that pricing, quantity, and downstream document flow stay synchronized.

Why California Redemption Value Matters for Beverage Distributors

California Redemption Value is a refundable deposit applied to eligible beverage containers under the state's beverage container recycling program. Consumers pay the deposit at purchase and recover it when they return the container for recycling. For distributors and retailers in the supply chain, CRV is not revenue in the ordinary sense; it is a pass-through amount that must be charged, tracked, and reported separately from the product price.

That separation is exactly why CRV cannot simply be built into a product's unit price. It needs to be visible as a distinct line on the sales document so that customers can see what they are paying, and so that the business can account for the deposit correctly. Any ERP handling for CRV therefore has to solve two things at once: automatically adding the fee whenever an eligible product is sold, and keeping that fee identifiable as belonging to a specific product line. The Acumatica configuration described below does both.

The CRV Data Flow at a Glance

Before looking at each screen, here is the full path a CRV line travels through Acumatica:

• A CRV item is created as a non-stock item representing the environmental fee.
• On the Stock Items (IN202500) screen, the Price/Cost tab of each eligible beverage product points to its CRV item through the CRV Item field.

• The CRV Amount field on the General tab of the Stock Items screen determines the fee amount based on the selected unit of measure.
• The Include in CRV checkbox on the customer's default location determines whether CRV applies to that customer at all.
• When the parent item is added to a sales order for an eligible customer, Acumatica automatically adds the associated CRV item as a new line with the same quantity and warehouse.
• Parent Item and Child Item fields on the Sales Orders, Shipments, and Invoices screens keep the product and its CRV line identifiable as a pair throughout the document flow.

Each field below sits at one of those handoffs, and knowing which stage a problem occurred at tells you which screen to open.

Step One: Configure the CRV Item as a Non-Stock Item

The flow begins with the fee itself. Before any product can reference a CRV charge, the CRV item must exist in Acumatica as a non-stock item. This is a prerequisite rather than a preference. The CRV Item field described in the next step expects a non-stock item, and configuring the fee as a stock item will break the association.

Businesses selling containers in more than one size category typically need more than one CRV item, since deposit amounts differ by container size under the state program. Setting these up as separate non-stock items, clearly named so that order entry staff and accounting can tell them apart on a document, is worth the small amount of extra effort at configuration time.

Step Two: Link the CRV Item to Its Parent Product

With the fee item in place, each eligible beverage product must be told which CRV item belongs to it. This association is made on the Stock Items screen and is the single most important link in the whole data flow. To configure it, navigate to the Stock Items screen, select the desired item, open the Price/Cost tab, and in the CRV Item field select the appropriate CRV item.

This field is what makes automatic CRV line creation possible. Without it, Acumatica has no way to know which fee applies to which product, and no child line will be generated when the product is sold. When a CRV charge fails to appear on an order, this field is the first place to check.

Step Three: Set the CRV Amount by Unit of Measure

The amount charged is controlled by the CRV Amount field on the General tab of the Stock Items screen. This field determines the amount for the associated CRV item based on the selected unit of measure, which allows a separate price to be defined for the CRV item independently of the product's own price.

The unit of measure dependency deserves attention during setup. Because deposits are levied per container, a product sold in multiple units of measure, such as individual bottles and cases, needs its CRV amount configured so that the resulting charge reflects the number of containers actually being sold. Reviewing this against a real order for each unit of measure you sell is a worthwhile validation step before going live.

Step Four: Enable Include in CRV on the Customer Location

The final piece of configuration determines which customers are charged. An Include in CRV checkbox has been added to the customer default location, and the status of that checkbox controls whether the CRV item is displayed on the sales order for that customer. Selected, and CRV lines are generated. Cleared, and they are not.

Placing this control at the location level rather than at the customer level is deliberate and useful. A customer with several ship-to locations may be subject to the deposit at some and not others, and the location record is where that distinction naturally lives. It also means CRV behavior can be adjusted for a specific customer relationship without touching item configuration that affects everyone.

How CRV Lines Are Created on the Sales Order

With configuration complete, the runtime behavior is simple and automatic. Navigate to the Sales Orders screen and select a customer whose location has the Include in CRV checkbox selected. When the main parent item is added to the order, the system automatically adds the associated CRV item as a new line.

Two attributes are inherited from the parent line rather than being entered by the user: the child CRV line receives the same quantity and the same warehouse as the parent item. This inheritance is what keeps the fee proportional to what is actually being sold. If ten cases are ordered, the CRV line reflects ten, and if the parent line ships from a particular warehouse, the CRV line is associated with that same warehouse. Order entry staff do not need to calculate, add, or adjust anything.

Parent Item and Child Item: Keeping CRV Lines Linked Downstream

A CRV line is only useful if you can tell which product it belongs to, and that becomes harder as documents multiply. To solve this, Parent Item and Child Item fields have been added to the Sales Orders, Shipments, and Invoices screens, specifically to identify the main item and its associated CRV item.

The significance of those three screens together is that the relationship survives the entire order-to-invoice flow. On the sales order, you can see which CRV line was generated by which product. When the order is shipped, the shipment document carries the same parent and child identification. When the invoice is produced, the association is still visible, so the customer's bill can be reconciled line by line and accounting can attribute every deposit to the product that generated it. This is what separates a properly modeled CRV implementation from one where fees appear as anonymous extra lines that nobody can trace.

Where to Monitor CRV Results in Acumatica

When configuring CRV, training users, or investigating an order where the fee looks wrong, these are the fields and screens that show what the system actually did:

• The CRV Item field on the Price/Cost tab of the Stock Items screen, which defines the association between a product and its fee item and is the first thing to check when no CRV line appears.
• The CRV Amount field on the General tab of the Stock Items screen, which sets the fee amount for the selected unit of measure.
• The Include in CRV checkbox on the customer default location, which determines whether CRV lines are generated for that customer at all.
• The non-stock status of the CRV item itself, since CRV items must always be non-stock items.
• The Parent Item and Child Item fields on the Sales Orders screen, which confirm that the generated CRV line is correctly associated with its product.
• The quantity and warehouse on the generated CRV line, which should match the parent line exactly.
• The Parent Item and Child Item fields on the Shipments screen, which confirm the association survived shipment creation.
• The Parent Item and Child Item fields on the Invoices screen, which is where the customer-facing result is verified and where accounting reconciles deposits against products sold.

CRV Processing in Acumatica: Frequently Asked Questions

What is a CRV item in Acumatica?

A CRV item is a non-stock item used in the inventory and sales modules to represent the California Redemption Value environmental fee attached to eligible beverage containers. It is added automatically to sales transactions when you sell beverages covered by California's recycling program, appearing as its own line alongside the product that generated it.

Does a CRV item have to be a non-stock item?

Yes. CRV items are only non-stock items. The fee represents a deposit rather than physical goods, and the CRV Item field on the Price/Cost tab of the Stock Items screen expects a non-stock item. Configuring the CRV item as a stock item will prevent the association from working correctly.

Why is the CRV line not appearing on my sales order?

Check three things in order. First, confirm that the Include in CRV checkbox is selected on the customer's default location, since this controls whether CRV items are displayed on the sales order for that customer. Second, confirm that the parent product has the correct CRV item selected in the CRV Item field on the Price/Cost tab of the Stock Items screen. Third, confirm that the CRV item itself is configured as a non-stock item.

How is the CRV amount determined?

The CRV Amount field on the General tab of the Stock Items screen determines the amount for the associated CRV item based on the selected unit of measure. This allows a separate price to be defined for the CRV item, independent of the product's own price, and lets the charge reflect the number of containers represented by the unit of measure being sold.

How do I tell which CRV line belongs to which product?

Use the Parent Item and Child Item fields, which have been added to the Sales Orders, Shipments, and Invoices screens specifically to identify the main item and its associated CRV item. Because those fields exist on all three screens, the relationship remains visible and traceable from order entry through shipment to the final invoice.

Can CRV be applied to some customers but not others?

Yes. The Include in CRV checkbox sits on the customer default location, so CRV behavior is controlled per location rather than globally. A customer with multiple ship-to locations can have the fee applied at some locations and not at others, without any change to item configuration.

What quantity and warehouse does the CRV line use?

The generated child CRV line inherits both from the parent item automatically. The same quantity and the same warehouse are set on the associated CRV line when the main item is added to the sales order, so the fee stays proportional to what is being sold and no manual adjustment is required during order entry.

Work With the Biz-Tech Services CRV Solution for Acumatica

CRV processing in Acumatica is compact but precise. A non-stock CRV item defines the fee, the CRV Item field on each product creates the association, the CRV Amount field sets the value per unit of measure, the Include in CRV checkbox decides which customers are charged, and the Parent Item and Child Item fields keep the fee traceable to its product across sales orders, shipments, and invoices. Configure those five things correctly and CRV billing takes care of itself on every order that follows.

If your business distributes beverages in California and needs redemption value charges applied automatically and reported accurately, we are glad to help you configure and validate CRV handling in your Acumatica environment. Visit https://biz-techservices.com to learn more about our Acumatica expertise or to schedule a personalized demonstration.

How CRV Lines Flow Through Sales Orders, Shipments, and Invoices in Acumatica

California Redemption Value, or CRV, has to appear on the invoice as its own line, and it has to stay attached to the product that generated it. That is the whole problem CRV processing in Acumatica solves. When a beverage item is added to a sales order, the system automatically creates a second line for its associated CRV item, carries the same quantity and warehouse across, and keeps the two lines linked by parent and child references all the way through shipments and invoices. Understanding where that child line comes from, which fields control whether it appears, and how the link survives downstream is what keeps CRV billing accurate.

The Biz-Tech Services CRV solution for Acumatica handles this automatically rather than asking order entry staff to remember an extra line on every beverage order. This article follows a CRV line through the full Acumatica data flow, from the item configuration that defines it to the invoice where it is billed, and identifies the fields users should monitor at each stage.

What a CRV Item Is in Acumatica

A CRV item in Acumatica is a non-stock item used across the inventory and sales modules to identify products that carry an environmental fee. It is automatically added to sales transactions when you sell beverages that fall under California's recycling program. The distinction that matters most is structural: CRV items are only ever non-stock items. They represent a fee rather than physical goods, so they must never be set up as stock items, and the configuration will not behave correctly if they are.

In practice this means every beverage product you sell has two records behind it. The parent item is the actual product being shipped, and the child CRV item is the environmental fee attached to that product. Acumatica keeps them associated so that pricing, quantity, and downstream document flow stay synchronized.

Why California Redemption Value Matters for Beverage Distributors

California Redemption Value is a refundable deposit applied to eligible beverage containers under the state's beverage container recycling program. Consumers pay the deposit at purchase and recover it when they return the container for recycling. For distributors and retailers in the supply chain, CRV is not revenue in the ordinary sense; it is a pass-through amount that must be charged, tracked, and reported separately from the product price.

That separation is exactly why CRV cannot simply be built into a product's unit price. It needs to be visible as a distinct line on the sales document so that customers can see what they are paying, and so that the business can account for the deposit correctly. Any ERP handling for CRV therefore has to solve two things at once: automatically adding the fee whenever an eligible product is sold, and keeping that fee identifiable as belonging to a specific product line. The Acumatica configuration described below does both.

The CRV Data Flow at a Glance

Before looking at each screen, here is the full path a CRV line travels through Acumatica:

• A CRV item is created as a non-stock item representing the environmental fee.
• On the Stock Items (IN202500) screen, the Price/Cost tab of each eligible beverage product points to its CRV item through the CRV Item field.

• The CRV Amount field on the General tab of the Stock Items screen determines the fee amount based on the selected unit of measure.
• The Include in CRV checkbox on the customer's default location determines whether CRV applies to that customer at all.
• When the parent item is added to a sales order for an eligible customer, Acumatica automatically adds the associated CRV item as a new line with the same quantity and warehouse.
• Parent Item and Child Item fields on the Sales Orders, Shipments, and Invoices screens keep the product and its CRV line identifiable as a pair throughout the document flow.

Each field below sits at one of those handoffs, and knowing which stage a problem occurred at tells you which screen to open.

Step One: Configure the CRV Item as a Non-Stock Item

The flow begins with the fee itself. Before any product can reference a CRV charge, the CRV item must exist in Acumatica as a non-stock item. This is a prerequisite rather than a preference. The CRV Item field described in the next step expects a non-stock item, and configuring the fee as a stock item will break the association.

Businesses selling containers in more than one size category typically need more than one CRV item, since deposit amounts differ by container size under the state program. Setting these up as separate non-stock items, clearly named so that order entry staff and accounting can tell them apart on a document, is worth the small amount of extra effort at configuration time.

Step Two: Link the CRV Item to Its Parent Product

With the fee item in place, each eligible beverage product must be told which CRV item belongs to it. This association is made on the Stock Items screen and is the single most important link in the whole data flow. To configure it, navigate to the Stock Items screen, select the desired item, open the Price/Cost tab, and in the CRV Item field select the appropriate CRV item.

This field is what makes automatic CRV line creation possible. Without it, Acumatica has no way to know which fee applies to which product, and no child line will be generated when the product is sold. When a CRV charge fails to appear on an order, this field is the first place to check.

Step Three: Set the CRV Amount by Unit of Measure

The amount charged is controlled by the CRV Amount field on the General tab of the Stock Items screen. This field determines the amount for the associated CRV item based on the selected unit of measure, which allows a separate price to be defined for the CRV item independently of the product's own price.

The unit of measure dependency deserves attention during setup. Because deposits are levied per container, a product sold in multiple units of measure, such as individual bottles and cases, needs its CRV amount configured so that the resulting charge reflects the number of containers actually being sold. Reviewing this against a real order for each unit of measure you sell is a worthwhile validation step before going live.

Step Four: Enable Include in CRV on the Customer Location

The final piece of configuration determines which customers are charged. An Include in CRV checkbox has been added to the customer default location, and the status of that checkbox controls whether the CRV item is displayed on the sales order for that customer. Selected, and CRV lines are generated. Cleared, and they are not.

Placing this control at the location level rather than at the customer level is deliberate and useful. A customer with several ship-to locations may be subject to the deposit at some and not others, and the location record is where that distinction naturally lives. It also means CRV behavior can be adjusted for a specific customer relationship without touching item configuration that affects everyone.

How CRV Lines Are Created on the Sales Order

With configuration complete, the runtime behavior is simple and automatic. Navigate to the Sales Orders screen and select a customer whose location has the Include in CRV checkbox selected. When the main parent item is added to the order, the system automatically adds the associated CRV item as a new line.

Two attributes are inherited from the parent line rather than being entered by the user: the child CRV line receives the same quantity and the same warehouse as the parent item. This inheritance is what keeps the fee proportional to what is actually being sold. If ten cases are ordered, the CRV line reflects ten, and if the parent line ships from a particular warehouse, the CRV line is associated with that same warehouse. Order entry staff do not need to calculate, add, or adjust anything.

Parent Item and Child Item: Keeping CRV Lines Linked Downstream

A CRV line is only useful if you can tell which product it belongs to, and that becomes harder as documents multiply. To solve this, Parent Item and Child Item fields have been added to the Sales Orders, Shipments, and Invoices screens, specifically to identify the main item and its associated CRV item.

The significance of those three screens together is that the relationship survives the entire order-to-invoice flow. On the sales order, you can see which CRV line was generated by which product. When the order is shipped, the shipment document carries the same parent and child identification. When the invoice is produced, the association is still visible, so the customer's bill can be reconciled line by line and accounting can attribute every deposit to the product that generated it. This is what separates a properly modeled CRV implementation from one where fees appear as anonymous extra lines that nobody can trace.

Where to Monitor CRV Results in Acumatica

When configuring CRV, training users, or investigating an order where the fee looks wrong, these are the fields and screens that show what the system actually did:

• The CRV Item field on the Price/Cost tab of the Stock Items screen, which defines the association between a product and its fee item and is the first thing to check when no CRV line appears.
• The CRV Amount field on the General tab of the Stock Items screen, which sets the fee amount for the selected unit of measure.
• The Include in CRV checkbox on the customer default location, which determines whether CRV lines are generated for that customer at all.
• The non-stock status of the CRV item itself, since CRV items must always be non-stock items.
• The Parent Item and Child Item fields on the Sales Orders screen, which confirm that the generated CRV line is correctly associated with its product.
• The quantity and warehouse on the generated CRV line, which should match the parent line exactly.
• The Parent Item and Child Item fields on the Shipments screen, which confirm the association survived shipment creation.
• The Parent Item and Child Item fields on the Invoices screen, which is where the customer-facing result is verified and where accounting reconciles deposits against products sold.

CRV Processing in Acumatica: Frequently Asked Questions

What is a CRV item in Acumatica?

A CRV item is a non-stock item used in the inventory and sales modules to represent the California Redemption Value environmental fee attached to eligible beverage containers. It is added automatically to sales transactions when you sell beverages covered by California's recycling program, appearing as its own line alongside the product that generated it.

Does a CRV item have to be a non-stock item?

Yes. CRV items are only non-stock items. The fee represents a deposit rather than physical goods, and the CRV Item field on the Price/Cost tab of the Stock Items screen expects a non-stock item. Configuring the CRV item as a stock item will prevent the association from working correctly.

Why is the CRV line not appearing on my sales order?

Check three things in order. First, confirm that the Include in CRV checkbox is selected on the customer's default location, since this controls whether CRV items are displayed on the sales order for that customer. Second, confirm that the parent product has the correct CRV item selected in the CRV Item field on the Price/Cost tab of the Stock Items screen. Third, confirm that the CRV item itself is configured as a non-stock item.

How is the CRV amount determined?

The CRV Amount field on the General tab of the Stock Items screen determines the amount for the associated CRV item based on the selected unit of measure. This allows a separate price to be defined for the CRV item, independent of the product's own price, and lets the charge reflect the number of containers represented by the unit of measure being sold.

How do I tell which CRV line belongs to which product?

Use the Parent Item and Child Item fields, which have been added to the Sales Orders, Shipments, and Invoices screens specifically to identify the main item and its associated CRV item. Because those fields exist on all three screens, the relationship remains visible and traceable from order entry through shipment to the final invoice.

Can CRV be applied to some customers but not others?

Yes. The Include in CRV checkbox sits on the customer default location, so CRV behavior is controlled per location rather than globally. A customer with multiple ship-to locations can have the fee applied at some locations and not at others, without any change to item configuration.

What quantity and warehouse does the CRV line use?

The generated child CRV line inherits both from the parent item automatically. The same quantity and the same warehouse are set on the associated CRV line when the main item is added to the sales order, so the fee stays proportional to what is being sold and no manual adjustment is required during order entry.

Work With the Biz-Tech Services CRV Solution for Acumatica

CRV processing in Acumatica is compact but precise. A non-stock CRV item defines the fee, the CRV Item field on each product creates the association, the CRV Amount field sets the value per unit of measure, the Include in CRV checkbox decides which customers are charged, and the Parent Item and Child Item fields keep the fee traceable to its product across sales orders, shipments, and invoices. Configure those five things correctly and CRV billing takes care of itself on every order that follows.

If your business distributes beverages in California and needs redemption value charges applied automatically and reported accurately, we are glad to help you configure and validate CRV handling in your Acumatica environment. Visit https://biz-techservices.com to learn more about our Acumatica expertise or to schedule a personalized demonstration.

---

by Gary

How Gift Card Processing Works in Acumatica from Sale to Redemption

How Gift Card Processing Works in Acumatica from Sale to Redemption

Gift Card Processing in Acumatica turns a gift card into two things at once: an item you sell and a payment method you later accept. That dual nature is what makes the data flow worth understanding. A gift card item is sold on a sales order, a serial number is generated and stored, a gift card record appears on the Payment Methods screen carrying its own balance, and every later redemption draws that balance down until nothing remains. Knowing where each record is created, which field holds the balance, and where to check the result is what keeps gift card liability accurate.

The Biz-Tech Services Gift Card Processing product, built for Acumatica, allows companies to sell serialized gift cards and then process those sold gift cards as payment. Gift cards grow sales, reinforce brand awareness, and are consistently preferred by customers over paper gift certificates. This article follows a gift card through the entire Acumatica data flow, from the preferences that define how it is numbered to the redemption that finally spends it, and points out the fields worth monitoring at every step.

What Gift Card Processing in Acumatica Does

Gift Card Processing is an Acumatica ERP customization that manages the full lifecycle of serialized gift cards. It lets you sell gift cards as either non-stock or stock inventory items, assigns each card a unique serial number, stores the card's value against the customer and order that created it, and then allows that stored value to be redeemed as a payment method on sales orders, invoices, and payments. Acumatica maintains a running Used Amount and Remaining Amount for every card, so the outstanding gift card balance is always visible and auditable. Cards can also be created directly from an external system through the API.

The Gift Card Data Flow at a Glance

Before looking at individual screens, it helps to see the path a gift card record travels through Acumatica:

• A gift card payment method is configured on the Payment Methods (CA204000) screen and linked to a dedicated cash account.

• Gift Card Preferences (BZ102000) defines how card numbers are generated and how external gift cards map to Acumatica items.
• A gift card item is sold on the Sales Orders (SO301000) screen, either as a non-stock item or as a serialized stock item.

• A serial number is generated and stored, and a gift card record appears on the Gift Cards tab of the Payment Methods screen with its customer, order, and amount.
• The card is redeemed as a payment method on a sales order, on Payments and Applications (AR302000), or on an invoice, with the serial number identifying which balance to draw from.
• Used Amount and Remaining Amount update on both the Payment Methods screen and the Gift Card History (BZ407099) screen after the payment is released.

Every field discussed below sits somewhere on that path. Identifying the stage tells you which screen holds the answer.

Setting the Foundation: The Gift Card Payment Method

The flow starts with a payment method, because a gift card is ultimately money. Payment methods are defined and viewed on the Payment Methods (CA204000) screen, and setting up gift cards begins by creating a new payment method there. Because payment methods are linked to cash accounts, it is strongly recommended to create a new general ledger account dedicated to the gift card item. Keeping gift card liability in its own account is what allows finance to see outstanding gift card value as a distinct number rather than buried in a general cash account.

Once that general ledger account exists, add the gift card cash account under the Allowed Cash Accounts tab of the payment method. One further field saves users time throughout the rest of the flow: the Default Gift Card field on the Payment Methods screen lets you nominate the gift card that will appear automatically in the Gift Card field of the Create Payment popup. With a default set, redemption becomes a matter of entering a serial number rather than selecting a card first.

Gift Card Preferences (BZ102000): Numbering and External Mapping

The Gift Card Preferences screen configures two things that shape every card created afterward: how gift card numbers are generated inside Acumatica, and how external gift cards map to Acumatica gift card items during order import.

Default Gift Card Item identifies the non-stock item treated as the default gift card during the order import process. Use Multiple Gift Cards in Commerce extends this by letting you map an external gift card SKU to its corresponding Acumatica gift card item, which is what makes orders containing several different gift cards import correctly. The fallback behavior is worth remembering: if Use Multiple Gift Cards in Commerce is not selected, the system defaults to the non-stock item named in Default Gift Card Item for every imported external order.

Sequential numbering versus random numbering

Selecting the Gift Card Numbering checkbox makes the Numbering Segments tab available, where you define the numbering structure for non-stock gift cards. Acumatica then generates card numbers according to that configuration. One detail is essential rather than optional: the Auto-Incremental Value must be configured in the Numbering Segments tab for gift card numbers to generate automatically.

Use Random Numbering takes the opposite approach and hides the Numbering Segments tab entirely. In this mode, Acumatica generates random numbers when a gift card item is entered on a sales order and a quantity is specified. The system produces as many random numbers as the entered quantity and displays them in the Gift Card Numbers popup. The security rationale matters: random numbering prevents anyone from guessing valid gift cards by following a predictable sequence. For cards distributed at scale, this is usually the safer choice.

Two Kinds of Gift Card Item: Non-Stock and Stock

Acumatica supports gift cards as either non-stock items or stock items, and the choice determines the shape of the early data flow. A non-stock gift card is the lighter path, suited to digital cards and to cards imported from external commerce systems. A stock gift card is a serialized physical inventory item that must be received before it can be sold, suited to physical cards held in a warehouse. Both converge on the same gift card record and the same redemption process, so the difference is confined to how the card comes into existence.

Selling a Non-Stock Gift Card Item in Acumatica

Non-stock gift card items are sold to customers on the standard Acumatica Sales Orders screen. The card can be sold directly within Acumatica or imported from an external system, after which the order proceeds to fulfillment as normal. The gift card number is generated and displayed in the Gift Card Numbers field on the Details tab of the sales order, and also in the Gift Card Numbers popup during order creation.

For orders created inside Acumatica, the gift card number can either be entered manually or generated according to the numbering setup in Gift Card Preferences. Three behaviors are worth knowing before users encounter them. The Gift Card Numbers popup displays the number belonging to the currently selected item line, so selecting a different line changes what you see. When the gift card quantity is greater than one, all of the generated numbers appear in that popup rather than on the line itself. And the shipping rule for a non-stock gift card automatically becomes Ship Complete on the sales order line.

Creating and Selling a Stock Gift Card Item

A stock gift card item is created from the Stock Items (IN202500) screen. Two configuration points make it function as a gift card. First, you must select the payment method to associate with the item for gift card payments. Second, because that field is enabled only for serialized items, a serial class specifically for the gift card item must be created on the Lot/Serial Classes screen. Serialization is what gives each physical card its own identity and its own balance.

Expiration dates are handled through the Track Expiration Date checkbox, which should be selected if gift cards are to expire. The timing matters: the gift card expiration date is established during the gift card receipt process, not at item creation.

The gift card receipt process

Stock gift cards must be received into inventory before they can be sold. Add the gift card item to the Receipts screen, enter the quantity, and generate the serial numbers together with their respective expiration dates from the Line Details popup window. Expiration dates appear here only when Track Expiration Date is selected on the serial class. At the end of this process, you hold a set of uniquely numbered, dated cards in inventory ready to sell.

Fulfilling a stock gift card order

Stock gift card items are sold on the same Sales Orders (SO301000) screen, but with one important difference: allocation is required for all stock gift card items. The specific card being sold must be chosen by selecting its serial number from the Lot/Serial Nbr field on the Line Details tab, which displays all available gift card serial numbers along with their expiration dates. This is the step that ties a physical card in your warehouse to a specific customer order.

Where the Gift Card Record Lives After the Sale

Once a gift card item is sold, whether stock or non-stock, the customer information, order information, and gift card amount are stored on the Gift Cards tab of the Payment Methods screen. This tab is the master record of every gift card in the system, and it displays Customer ID, Inventory ID, Gift Card Serial Number, Order Number, Gift Card Amount, Used Amount, and Remaining Amount.

Those last two fields are the ones to watch. As a gift card is used, Acumatica updates the Used Amount and Remaining Amount on this tab, so the outstanding balance of any card is always one screen away. Clicking a serial number opens the Gift Card History screen, which shows all transactions related to that card. Together these two views answer the two questions users actually ask: what is left on this card, and what has been done with it.

Redeeming a Gift Card as a Payment Method in Acumatica

Redemption is where a sold gift card becomes tender, and Acumatica supports three routes. All three follow the same underlying pattern: choose the gift card payment method, identify the specific card by serial number, and release the payment.

Redeeming on a sales order

On the Sales Orders (SO301000) screen, select Gift Card Payment as the payment method. This reveals the Gift Card field in the Create Payment popup. If a default gift card has been configured on the payment method, it appears automatically; if not, select it manually. Then enter the serial number of the card being redeemed, which can also be typed manually. Proceed with order fulfillment afterward, and note that the payment for the order must be released for the redemption to take effect.

Redeeming on Payments and Applications

Gift cards can also be processed on the Payments and Applications (AR302000) screen. Navigate to the screen and select the appropriate payment method and cash account, after which the Gift Card field appears. The default card populates automatically if one is configured, otherwise select it manually and enter the serial number. Once all required fields are complete, release the payment.

Redeeming against an invoice

The third route runs through the Invoices (SO303000) screen. Create an invoice by adding either the corresponding sales order or the relevant items. Create a payment from the Applications tab within the invoice, choose the gift card payment method, which displays the Gift Card field in the Create Payment popup, select the card if no default is set, and enter its serial number. Release the invoice and complete the payment process.

After both the invoice and the payment have been released, Acumatica updates the Used Amount and Remaining Amount fields in two places at once: the Gift Card tab of the Payment Methods screen and the Gift Card History screen. Those two screens agreeing is the confirmation that a redemption posted correctly.

The Gift Card Return Process

Returns follow standard Acumatica return-for-credit mechanics. Create a return order of the RC type on the Sales Orders (SO301000) form and add the line or lines from the sales invoice prepared for the original order. Receive the returned items back into inventory on the Shipments (SO302000) form by creating a shipment with the Receipt operation and confirming it. Then create a credit memo to decrease the customer's debt by the amount of the returned items, review its details on the Invoices (SO303000) form, and release it.

For gift card items specifically, the return can also be handled by adding the corresponding gift card items to an RC type return order on the Sales Orders form and selecting the serial number from the Sold Serial Numbers tab of the Line Details. That tab exists precisely so that a returned card can be matched to the exact serial that was sold. Once the return transaction is processed, Acumatica updates the amount information on the Gift Card History screen, which is where you verify that the returned card's balance was corrected.

Gift Card History and Gift Card Summary Screens

The Gift Card History (BZ407099) screen displays all information related to a given gift card and serves as the transaction ledger for that card. It is also a creation point: the Create Gift Card button opens a popup where the required data can be entered and confirmed with OK to create a card directly, without going through a sales order.

Two flags on this screen classify each card and are useful when filtering or troubleshooting. External Gift Card indicates that the card was imported from an external system, and Is Stock Gift Card indicates whether the card is a stock or non-stock item. The separate Gift Card Summary screen displays all related information for a gift card in consolidated form, and it also serves as the outbound channel for sending gift card summary details from Acumatica to an external system.

Creating Gift Cards from an External System via API

Gift card information can be imported into Acumatica from an external system through the API using the Biztech endpoint. The Create Gift Card action within the Gift Card History endpoint is what accepts inbound card data. Once the API request is processed, the gift card details, including customer information, serial number, and amount, appear on the Payment Methods screen under the Gift Card tab, and the same information becomes available on both the Gift

Card Summary and Gift Card History screens.

This matters for the data flow because it means a gift card does not have to originate from an Acumatica sales order. A card sold in an external commerce platform, a point of sale system, or a marketing campaign can enter Acumatica through the API and then behave exactly like any internally sold card, including being redeemed as a payment method and tracked through the same balance fields.

Where to Monitor Gift Card Processing Results in Acumatica

When training users or investigating a gift card that does not behave as expected, these are the fields and screens that show what the system actually did:

• Gift Card Serial Number on the Gift Cards tab of the Payment Methods screen, which uniquely identifies every card and links to its history.
• Gift Card Amount, Used Amount, and Remaining Amount, which together give the original value, the consumed value, and the current balance.
• Customer ID, Inventory ID, and Order Number on the same tab, which tie a card back to who bought it and on which order.
• The Gift Card History (BZ407099) screen, reached by clicking a serial number, which lists all transactions for that card and reflects return adjustments.
• The Gift Card Numbers popup on the sales order, remembering that it shows numbers for the selected line and lists every number when the quantity exceeds one.
• Lot/Serial Nbr on the Line Details tab for stock gift cards, which shows available serial numbers with their expiration dates during allocation.
• The Sold Serial Numbers tab of Line Details, used to match a returned card to the serial number originally sold.
• External Gift Card and Is Stock Gift Card flags on the Gift Card History screen, which classify how a card entered the system and what type it is.
• The dedicated gift card cash account and general ledger account, which is where outstanding gift card liability should be reviewed by finance.

Gift Card Processing in Acumatica: Frequently Asked Questions

What is Gift Card Processing in Acumatica?

Gift Card Processing is an Acumatica ERP customization from Biz-Tech Services that lets companies sell serialized gift cards and then accept those cards as a payment method. Each card carries a unique serial number and its own balance, tracked through Gift Card Amount, Used Amount, and Remaining Amount fields on the Payment Methods screen, with a full transaction history available on the Gift Card History screen.

What is the difference between a stock and a non-stock gift card item?

A non-stock gift card is created and sold without inventory receipt, which suits digital cards and cards imported from external commerce systems. A stock gift card is a serialized inventory item created on the Stock Items (IN202500) screen that must be received through the gift card receipt process before it can be sold, and it requires allocation of a specific serial number at the time of sale. Both card types produce the same gift card record and are redeemed identically.

How are gift card numbers generated in Acumatica?

Gift Card Preferences (BZ102000) controls this. With the Gift Card Numbering checkbox selected, numbers follow the structure defined on the Numbering Segments tab, and the Auto-Incremental Value must be configured for automatic generation. With Use Random Numbering selected instead, the Numbering Segments tab is hidden and Acumatica generates random numbers based on the quantity entered on the sales order, which prevents anyone from predicting valid card numbers. Numbers can also be entered manually for orders created inside Acumatica.

How do you redeem a gift card in Acumatica?

There are three routes. On the Sales Orders (SO301000) screen, select Gift Card Payment as the payment method, then supply the card and its serial number in the Create Payment popup. On Payments and Applications (AR302000), select the payment method and cash account, then the card and serial number. On the Invoices (SO303000) screen, create a payment from the Applications tab and do the same. In every case the payment must be released for the balance to update.

Where do you check a gift card balance in Acumatica?

Open the Gift Cards tab of the Payment Methods screen and locate the card by serial number. The Remaining Amount field shows the current balance, with Gift Card Amount showing the original value and Used Amount showing what has been consumed. Clicking the serial number opens the Gift Card History screen for the full transaction detail behind those figures.

Can gift cards be returned in Acumatica?

Yes. Create a return order of the RC type on the Sales Orders (SO301000) form, add the relevant lines, receive the items on the Shipments (SO302000) form using the Receipt operation, then create and release a credit memo through the Invoices (SO303000) form. For gift card items you can select the specific card from the Sold Serial Numbers tab of the Line Details. Once the return is processed, the amount information updates on the Gift Card History screen.

Can gift cards be created from an external system?

Yes. Gift card information can be imported into Acumatica through the API using the Biztech endpoint, via the Create Gift Card action in the Gift Card History endpoint. After the request is processed, the customer information, serial number, and amount appear on the Gift Card tab of the Payment Methods screen and on both the Gift Card Summary and Gift Card History screens. Cards can also be created manually with the Create Gift Card button on the Gift Card History screen.

Work With the Biz-Tech Services Gift Card Processing Product

Gift Card Processing in Acumatica becomes straightforward once the flow is clear. The payment method and its dedicated cash account establish where gift card value lives, preferences decide how cards are numbered and mapped, the sales order creates the card and its serial number, the Payment Methods screen holds the balance, redemption draws that balance down through any of three screens, and the Gift Card History screen records everything that happened along the way. Teams that know which field governs each handoff can answer any gift card question in seconds.

If your business wants to sell gift cards, accept them as payment, and keep outstanding gift card liability visible and accurate, we are glad to help you scope, configure, and roll out Gift Card Processing in Acumatica. Visit https://biz-techservices.com to learn more about our Acumatica expertise or to schedule a personalized demonstration of the Biz-Tech Services Gift Card Processing product.

How Gift Card Processing Works in Acumatica from Sale to Redemption

Gift Card Processing in Acumatica turns a gift card into two things at once: an item you sell and a payment method you later accept. That dual nature is what makes the data flow worth understanding. A gift card item is sold on a sales order, a serial number is generated and stored, a gift card record appears on the Payment Methods screen carrying its own balance, and every later redemption draws that balance down until nothing remains. Knowing where each record is created, which field holds the balance, and where to check the result is what keeps gift card liability accurate.

The Biz-Tech Services Gift Card Processing product, built for Acumatica, allows companies to sell serialized gift cards and then process those sold gift cards as payment. Gift cards grow sales, reinforce brand awareness, and are consistently preferred by customers over paper gift certificates. This article follows a gift card through the entire Acumatica data flow, from the preferences that define how it is numbered to the redemption that finally spends it, and points out the fields worth monitoring at every step.

What Gift Card Processing in Acumatica Does

Gift Card Processing is an Acumatica ERP customization that manages the full lifecycle of serialized gift cards. It lets you sell gift cards as either non-stock or stock inventory items, assigns each card a unique serial number, stores the card's value against the customer and order that created it, and then allows that stored value to be redeemed as a payment method on sales orders, invoices, and payments. Acumatica maintains a running Used Amount and Remaining Amount for every card, so the outstanding gift card balance is always visible and auditable. Cards can also be created directly from an external system through the API.

The Gift Card Data Flow at a Glance

Before looking at individual screens, it helps to see the path a gift card record travels through Acumatica:

• A gift card payment method is configured on the Payment Methods (CA204000) screen and linked to a dedicated cash account.

• Gift Card Preferences (BZ102000) defines how card numbers are generated and how external gift cards map to Acumatica items.
• A gift card item is sold on the Sales Orders (SO301000) screen, either as a non-stock item or as a serialized stock item.

• A serial number is generated and stored, and a gift card record appears on the Gift Cards tab of the Payment Methods screen with its customer, order, and amount.
• The card is redeemed as a payment method on a sales order, on Payments and Applications (AR302000), or on an invoice, with the serial number identifying which balance to draw from.
• Used Amount and Remaining Amount update on both the Payment Methods screen and the Gift Card History (BZ407099) screen after the payment is released.

Every field discussed below sits somewhere on that path. Identifying the stage tells you which screen holds the answer.

Setting the Foundation: The Gift Card Payment Method

The flow starts with a payment method, because a gift card is ultimately money. Payment methods are defined and viewed on the Payment Methods (CA204000) screen, and setting up gift cards begins by creating a new payment method there. Because payment methods are linked to cash accounts, it is strongly recommended to create a new general ledger account dedicated to the gift card item. Keeping gift card liability in its own account is what allows finance to see outstanding gift card value as a distinct number rather than buried in a general cash account.

Once that general ledger account exists, add the gift card cash account under the Allowed Cash Accounts tab of the payment method. One further field saves users time throughout the rest of the flow: the Default Gift Card field on the Payment Methods screen lets you nominate the gift card that will appear automatically in the Gift Card field of the Create Payment popup. With a default set, redemption becomes a matter of entering a serial number rather than selecting a card first.

Gift Card Preferences (BZ102000): Numbering and External Mapping

The Gift Card Preferences screen configures two things that shape every card created afterward: how gift card numbers are generated inside Acumatica, and how external gift cards map to Acumatica gift card items during order import.

Default Gift Card Item identifies the non-stock item treated as the default gift card during the order import process. Use Multiple Gift Cards in Commerce extends this by letting you map an external gift card SKU to its corresponding Acumatica gift card item, which is what makes orders containing several different gift cards import correctly. The fallback behavior is worth remembering: if Use Multiple Gift Cards in Commerce is not selected, the system defaults to the non-stock item named in Default Gift Card Item for every imported external order.

Sequential numbering versus random numbering

Selecting the Gift Card Numbering checkbox makes the Numbering Segments tab available, where you define the numbering structure for non-stock gift cards. Acumatica then generates card numbers according to that configuration. One detail is essential rather than optional: the Auto-Incremental Value must be configured in the Numbering Segments tab for gift card numbers to generate automatically.

Use Random Numbering takes the opposite approach and hides the Numbering Segments tab entirely. In this mode, Acumatica generates random numbers when a gift card item is entered on a sales order and a quantity is specified. The system produces as many random numbers as the entered quantity and displays them in the Gift Card Numbers popup. The security rationale matters: random numbering prevents anyone from guessing valid gift cards by following a predictable sequence. For cards distributed at scale, this is usually the safer choice.

Two Kinds of Gift Card Item: Non-Stock and Stock

Acumatica supports gift cards as either non-stock items or stock items, and the choice determines the shape of the early data flow. A non-stock gift card is the lighter path, suited to digital cards and to cards imported from external commerce systems. A stock gift card is a serialized physical inventory item that must be received before it can be sold, suited to physical cards held in a warehouse. Both converge on the same gift card record and the same redemption process, so the difference is confined to how the card comes into existence.

Selling a Non-Stock Gift Card Item in Acumatica

Non-stock gift card items are sold to customers on the standard Acumatica Sales Orders screen. The card can be sold directly within Acumatica or imported from an external system, after which the order proceeds to fulfillment as normal. The gift card number is generated and displayed in the Gift Card Numbers field on the Details tab of the sales order, and also in the Gift Card Numbers popup during order creation.

For orders created inside Acumatica, the gift card number can either be entered manually or generated according to the numbering setup in Gift Card Preferences. Three behaviors are worth knowing before users encounter them. The Gift Card Numbers popup displays the number belonging to the currently selected item line, so selecting a different line changes what you see. When the gift card quantity is greater than one, all of the generated numbers appear in that popup rather than on the line itself. And the shipping rule for a non-stock gift card automatically becomes Ship Complete on the sales order line.

Creating and Selling a Stock Gift Card Item

A stock gift card item is created from the Stock Items (IN202500) screen. Two configuration points make it function as a gift card. First, you must select the payment method to associate with the item for gift card payments. Second, because that field is enabled only for serialized items, a serial class specifically for the gift card item must be created on the Lot/Serial Classes screen. Serialization is what gives each physical card its own identity and its own balance.

Expiration dates are handled through the Track Expiration Date checkbox, which should be selected if gift cards are to expire. The timing matters: the gift card expiration date is established during the gift card receipt process, not at item creation.

The gift card receipt process

Stock gift cards must be received into inventory before they can be sold. Add the gift card item to the Receipts screen, enter the quantity, and generate the serial numbers together with their respective expiration dates from the Line Details popup window. Expiration dates appear here only when Track Expiration Date is selected on the serial class. At the end of this process, you hold a set of uniquely numbered, dated cards in inventory ready to sell.

Fulfilling a stock gift card order

Stock gift card items are sold on the same Sales Orders (SO301000) screen, but with one important difference: allocation is required for all stock gift card items. The specific card being sold must be chosen by selecting its serial number from the Lot/Serial Nbr field on the Line Details tab, which displays all available gift card serial numbers along with their expiration dates. This is the step that ties a physical card in your warehouse to a specific customer order.

Where the Gift Card Record Lives After the Sale

Once a gift card item is sold, whether stock or non-stock, the customer information, order information, and gift card amount are stored on the Gift Cards tab of the Payment Methods screen. This tab is the master record of every gift card in the system, and it displays Customer ID, Inventory ID, Gift Card Serial Number, Order Number, Gift Card Amount, Used Amount, and Remaining Amount.

Those last two fields are the ones to watch. As a gift card is used, Acumatica updates the Used Amount and Remaining Amount on this tab, so the outstanding balance of any card is always one screen away. Clicking a serial number opens the Gift Card History screen, which shows all transactions related to that card. Together these two views answer the two questions users actually ask: what is left on this card, and what has been done with it.

Redeeming a Gift Card as a Payment Method in Acumatica

Redemption is where a sold gift card becomes tender, and Acumatica supports three routes. All three follow the same underlying pattern: choose the gift card payment method, identify the specific card by serial number, and release the payment.

Redeeming on a sales order

On the Sales Orders (SO301000) screen, select Gift Card Payment as the payment method. This reveals the Gift Card field in the Create Payment popup. If a default gift card has been configured on the payment method, it appears automatically; if not, select it manually. Then enter the serial number of the card being redeemed, which can also be typed manually. Proceed with order fulfillment afterward, and note that the payment for the order must be released for the redemption to take effect.

Redeeming on Payments and Applications

Gift cards can also be processed on the Payments and Applications (AR302000) screen. Navigate to the screen and select the appropriate payment method and cash account, after which the Gift Card field appears. The default card populates automatically if one is configured, otherwise select it manually and enter the serial number. Once all required fields are complete, release the payment.

Redeeming against an invoice

The third route runs through the Invoices (SO303000) screen. Create an invoice by adding either the corresponding sales order or the relevant items. Create a payment from the Applications tab within the invoice, choose the gift card payment method, which displays the Gift Card field in the Create Payment popup, select the card if no default is set, and enter its serial number. Release the invoice and complete the payment process.

After both the invoice and the payment have been released, Acumatica updates the Used Amount and Remaining Amount fields in two places at once: the Gift Card tab of the Payment Methods screen and the Gift Card History screen. Those two screens agreeing is the confirmation that a redemption posted correctly.

The Gift Card Return Process

Returns follow standard Acumatica return-for-credit mechanics. Create a return order of the RC type on the Sales Orders (SO301000) form and add the line or lines from the sales invoice prepared for the original order. Receive the returned items back into inventory on the Shipments (SO302000) form by creating a shipment with the Receipt operation and confirming it. Then create a credit memo to decrease the customer's debt by the amount of the returned items, review its details on the Invoices (SO303000) form, and release it.

For gift card items specifically, the return can also be handled by adding the corresponding gift card items to an RC type return order on the Sales Orders form and selecting the serial number from the Sold Serial Numbers tab of the Line Details. That tab exists precisely so that a returned card can be matched to the exact serial that was sold. Once the return transaction is processed, Acumatica updates the amount information on the Gift Card History screen, which is where you verify that the returned card's balance was corrected.

Gift Card History and Gift Card Summary Screens

The Gift Card History (BZ407099) screen displays all information related to a given gift card and serves as the transaction ledger for that card. It is also a creation point: the Create Gift Card button opens a popup where the required data can be entered and confirmed with OK to create a card directly, without going through a sales order.

Two flags on this screen classify each card and are useful when filtering or troubleshooting. External Gift Card indicates that the card was imported from an external system, and Is Stock Gift Card indicates whether the card is a stock or non-stock item. The separate Gift Card Summary screen displays all related information for a gift card in consolidated form, and it also serves as the outbound channel for sending gift card summary details from Acumatica to an external system.

Creating Gift Cards from an External System via API

Gift card information can be imported into Acumatica from an external system through the API using the Biztech endpoint. The Create Gift Card action within the Gift Card History endpoint is what accepts inbound card data. Once the API request is processed, the gift card details, including customer information, serial number, and amount, appear on the Payment Methods screen under the Gift Card tab, and the same information becomes available on both the Gift

Card Summary and Gift Card History screens.

This matters for the data flow because it means a gift card does not have to originate from an Acumatica sales order. A card sold in an external commerce platform, a point of sale system, or a marketing campaign can enter Acumatica through the API and then behave exactly like any internally sold card, including being redeemed as a payment method and tracked through the same balance fields.

Where to Monitor Gift Card Processing Results in Acumatica

When training users or investigating a gift card that does not behave as expected, these are the fields and screens that show what the system actually did:

• Gift Card Serial Number on the Gift Cards tab of the Payment Methods screen, which uniquely identifies every card and links to its history.
• Gift Card Amount, Used Amount, and Remaining Amount, which together give the original value, the consumed value, and the current balance.
• Customer ID, Inventory ID, and Order Number on the same tab, which tie a card back to who bought it and on which order.
• The Gift Card History (BZ407099) screen, reached by clicking a serial number, which lists all transactions for that card and reflects return adjustments.
• The Gift Card Numbers popup on the sales order, remembering that it shows numbers for the selected line and lists every number when the quantity exceeds one.
• Lot/Serial Nbr on the Line Details tab for stock gift cards, which shows available serial numbers with their expiration dates during allocation.
• The Sold Serial Numbers tab of Line Details, used to match a returned card to the serial number originally sold.
• External Gift Card and Is Stock Gift Card flags on the Gift Card History screen, which classify how a card entered the system and what type it is.
• The dedicated gift card cash account and general ledger account, which is where outstanding gift card liability should be reviewed by finance.

Gift Card Processing in Acumatica: Frequently Asked Questions

What is Gift Card Processing in Acumatica?

Gift Card Processing is an Acumatica ERP customization from Biz-Tech Services that lets companies sell serialized gift cards and then accept those cards as a payment method. Each card carries a unique serial number and its own balance, tracked through Gift Card Amount, Used Amount, and Remaining Amount fields on the Payment Methods screen, with a full transaction history available on the Gift Card History screen.

What is the difference between a stock and a non-stock gift card item?

A non-stock gift card is created and sold without inventory receipt, which suits digital cards and cards imported from external commerce systems. A stock gift card is a serialized inventory item created on the Stock Items (IN202500) screen that must be received through the gift card receipt process before it can be sold, and it requires allocation of a specific serial number at the time of sale. Both card types produce the same gift card record and are redeemed identically.

How are gift card numbers generated in Acumatica?

Gift Card Preferences (BZ102000) controls this. With the Gift Card Numbering checkbox selected, numbers follow the structure defined on the Numbering Segments tab, and the Auto-Incremental Value must be configured for automatic generation. With Use Random Numbering selected instead, the Numbering Segments tab is hidden and Acumatica generates random numbers based on the quantity entered on the sales order, which prevents anyone from predicting valid card numbers. Numbers can also be entered manually for orders created inside Acumatica.

How do you redeem a gift card in Acumatica?

There are three routes. On the Sales Orders (SO301000) screen, select Gift Card Payment as the payment method, then supply the card and its serial number in the Create Payment popup. On Payments and Applications (AR302000), select the payment method and cash account, then the card and serial number. On the Invoices (SO303000) screen, create a payment from the Applications tab and do the same. In every case the payment must be released for the balance to update.

Where do you check a gift card balance in Acumatica?

Open the Gift Cards tab of the Payment Methods screen and locate the card by serial number. The Remaining Amount field shows the current balance, with Gift Card Amount showing the original value and Used Amount showing what has been consumed. Clicking the serial number opens the Gift Card History screen for the full transaction detail behind those figures.

Can gift cards be returned in Acumatica?

Yes. Create a return order of the RC type on the Sales Orders (SO301000) form, add the relevant lines, receive the items on the Shipments (SO302000) form using the Receipt operation, then create and release a credit memo through the Invoices (SO303000) form. For gift card items you can select the specific card from the Sold Serial Numbers tab of the Line Details. Once the return is processed, the amount information updates on the Gift Card History screen.

Can gift cards be created from an external system?

Yes. Gift card information can be imported into Acumatica through the API using the Biztech endpoint, via the Create Gift Card action in the Gift Card History endpoint. After the request is processed, the customer information, serial number, and amount appear on the Gift Card tab of the Payment Methods screen and on both the Gift Card Summary and Gift Card History screens. Cards can also be created manually with the Create Gift Card button on the Gift Card History screen.

Work With the Biz-Tech Services Gift Card Processing Product

Gift Card Processing in Acumatica becomes straightforward once the flow is clear. The payment method and its dedicated cash account establish where gift card value lives, preferences decide how cards are numbered and mapped, the sales order creates the card and its serial number, the Payment Methods screen holds the balance, redemption draws that balance down through any of three screens, and the Gift Card History screen records everything that happened along the way. Teams that know which field governs each handoff can answer any gift card question in seconds.

If your business wants to sell gift cards, accept them as payment, and keep outstanding gift card liability visible and accurate, we are glad to help you scope, configure, and roll out Gift Card Processing in Acumatica. Visit https://biz-techservices.com to learn more about our Acumatica expertise or to schedule a personalized demonstration of the Biz-Tech Services Gift Card Processing product.

---

by Gary

How Kit Processing Works in Acumatica from Order Entry to Fulfillment

How Kit Processing Works in Acumatica from Order Entry to Fulfillment

Kit Processing in Acumatica is easiest to understand as a data flow rather than as a screen. A single kit record starts life on the Kit Specifications form, picks up defaults from your preferences screens, becomes a line on a sales order, splits into a placeholder and a set of components, and finally resolves into a shipment, an invoice, and a set of inventory transactions. Every problem a user ever reports with kits traces back to one of those handoffs. Understanding where each record is created, which field controls the next step, and where the result becomes visible is what makes the module predictable.

The Biz-Tech Services Kit Processing product lets users explode kit components directly on the Sales Orders screen, with no need to open a separate maintenance form or print a pick list just to see what a kit contains. Cost calculation for kit items is controlled from the native Sales Order Preferences screen, which gives companies flexibility without forcing maintenance adjustments to inventory items. This article follows a kit through the entire Acumatica data flow, from the specification that defines it to the released invoice that closes it out, and points out the fields worth watching at each stage.

Stage One: The Kit Specification Is the Source of Every Record

Everything downstream inherits from the Kit Specifications form, so this is where the data flow begins. The form is available only when the Kit Assembly feature is enabled on the Enable/Disable Features (CS100000) form, and you can create a kit specification only for an inventory item that has already been marked as a kit on the General tab of the Stock Items (IN202500) or Non-Stock Items (IN202000) form. That marking is the true origin point of the record. Without it, no specification can exist.

The header fields define the identity of the kit. Kit Inventory ID is the inventory identifier of the kit as assigned on the stock or non-stock item form, and Non-Stock is a read-only checkbox indicating that the kit is a non-stock kit. Revision ID uniquely identifies each revision of the specification, and Description holds a brief summary. Two checkboxes govern whether the record participates in the flow at all: Active marks the specification as usable, and Current Revision indicates which revision the system will actually use when the kit explodes on a sales order. If a kit item already has a current revision and you attempt to change it, the system warns you that saving will uncheck the previous one. Only one revision is current at a time, and that is the revision the rest of the flow will read.

Explode Kit is the field that determines whether the kit will break into its components on the Sales Orders screen. Selecting it activates three further fields that shape the entire downstream flow: Kit Placeholder Item, Explode Option, and Price Calculation. Kit has options adds Option Category and Option Codes tabs, where you define the choices a user will be asked to make during order entry. Marking an option category as Required forces the user to select a code in the Options popup before the kit order can proceed, while Sort Order controls whether categories appear in ascending or descending order in the Sales Orders dropdown. Default Code automatically includes an option code in the order without user input, which matters a great deal for any path where no human is present to choose: API calls, import scenarios, processing screens, and opportunities or sales quotes.

Three further checkboxes extend what users can change later in the flow. Allow Option Rules adds an Option Rule tab, where a source option category and code exclude a target option category and code on the Sales Orders screen. If Size 8x10 is configured to exclude the color Black, a user who selects 8x10 will not be offered Black; selecting a size that is not covered by a rule, such as 8x12, makes Black available again. Allow Component Substitution adds a Substitution tab and a matching column on the Stock Components tab, letting you nominate replacement items for specific components. Allow Component Addition activates the Add Row option in the Component Details dialog on the Sales Orders screen, permitting new components to be added before the kit explodes.

Two structural rules belong here because they cause real problems when missed. First, the Unit of Measure of the Kit Placeholder Item must match the Unit of Measure of the kit item, or the system raises a warning. Second, for nested kits, where a kit item is used as a component or option inside another kit, the main kit is the Parent Kit and the included kit is the Child Kit. If a non-stock kit is used as a component or option, the Explode Option for both the parent and the child must be set to Automatically. The same requirement applies when a non-stock kit contains a stock option item, because only automatic explosion ensures the stock option is allocated during shipment.

Stage Two: Acumatica Preferences Supply the Defaults That Flow Downstream

The second stage of the Acumatica Kit Processing data flow is the Biz-Tech Services Kit Processing Settings section on the Sales Orders Preferences screen, with an equivalent section on the Purchase Orders Preferences screen. Price Calculation for Kits, Kit Placeholder Item, and Explode Option are general settings that apply to every kit. The precedence rule is simple and worth teaching to every user: if those same settings are configured manually for a specific kit on the Kit Specifications screen, the system prioritizes the kit-level setting over the general one. When a kit behaves differently from what preferences suggest, the specification is almost always the reason. If the specific item has already configyration done in Kit Specifications screen, then the setup of individual item would be used

Several preference fields change how quantities and documents behave later in the flow. Not Calculate Component Quantities bases quantity calculation in sales orders on the quantity specified for the kit itself. Invoice After Full Shipment allows partial shipment and holds the placeholder item back until every component has shipped. Use Kit Posting Group places the kit item's account and subaccount values on the placeholder row after explosion, and Apply to the Components extends those same values to the component rows. Allow Kit Assembly Generation enables the assembly branch described later. Unexploded Kit Price Calculation by Components prevents the kit from exploding and calculates only the price of the components toward the order total, which is why selecting it triggers a warning that the Explode Kit checkbox should be unchecked.

Components Qty. Is Required for Kit Item Ship deserves particular attention, because it decides whether a shipment can be created at all. Selecting it reveals a dropdown with three shipping behaviors. Ship Available Qty. sets the kit or placeholder line to back order allowed and lets a shipment be created for the minimum component quantity, without requiring every component to be available. Ship Ordered Qty. requires all components to be available and allocated based on the kit quantity, so nothing ships until everything is ready. The third option allows back order without requiring component quantity to be available for shipping. Finally, Allow Edit Exploded Kit Component gives users control over component quantities after explosion and permits deletion of kit components on the Sales Orders screen, and it has the same effect on the Purchase Orders screen when set in purchase order preferences.

Two settings outside these screens can also stop the flow. Selecting Block Kit Items Explosion on the Customers or Vendors screen prevents kits from exploding for that business account, and the same checkbox in the Biz-Tech Kit Processing Settings on the Order Types screen prevents explosion for that order type. Both override the explode option on the kit itself, so they are the first place to look when a kit refuses to explode for one customer or one order type but works everywhere else.

Stage Three: Sales Order Entry and the Component Details Window

Once a kit item is added to a sales order, the flow moves into the Component Details popup, which is the working surface for everything that happens before explosion. If the kit has options, an Options popup opens automatically when the kit item is entered, prompting the user to select an option code for each option category before pressing OK. Those selections can still be revised without exploding the kit by using the Change Options button in Component Details; all previous option category and option code configurations remain intact unless they are manually changed.

Before explosion, Component Details is where the order line is shaped. Users can add or delete components, and they can exchange a component for an approved substitute by double-clicking the item and choosing the replacement from the search icon that appears beside it. This window is also the point where purchasing can be triggered. Selecting the Mark for PO checkbox for a component and clicking Create PO generates a purchase order, and the resulting purchase order number is displayed under the PO Number field in Component Details. The required quantity must have a value for the purchase order to be created. Purchase orders are created according to the Default Vendor ID of each component, and when several components share the same vendor, a single purchase order covers them all. If that purchase order or its lines are later deleted, the number is removed from Component Details automatically, which keeps the reference trustworthy.

Stage Four: Acumatica Kit Explosion and the Placeholder Item

Explosion is the pivotal transformation in the Biz-Tech Services Acumatica Kit Processing flow, because it is the moment one order line becomes many. A kit explodes in one of two ways: by clicking Load Components in the Component Details dialog, or simply by assigning a quantity to the newly added kit on the sales order. Which of these is even possible depends on the Explode Option chosen earlier. Prompt asks the user whether to explode, Automatically explodes without user intervention, and Do Not Explode prevents explosion entirely.

When the kit explodes, the kit placeholder item and its components appear on the sales order lines with their respective prices, quantities, and costs. The placeholder is a non-stock item that replaces the kit item on the Sales Orders screen after explosion. Its purpose is financial accuracy: a kit item consists of multiple components, and when those components are added to the order as real lines, leaving the original kit item in place would double-count item cost. The placeholder behaves like the kit item in the order but contains no actual items. One field on that placeholder row is worth monitoring closely. Total Cost of Components is calculated as the component's unit cost at the time the sales order was created, which does not change afterward, multiplied by the quantity. It is displayed on the kit placeholder row and carried forward to the invoice, making it the natural checkpoint for verifying kit margin.

Price Calculation determines what the customer is charged, and it offers three methods. Use Kit Default Price applies the kit's own default price, plus any manually added price for its options. Use Component Default Price bases the price on each component's default price and sets the kit item price to zero. Use Combined Default Price adds the kit's default price to the default prices of the components. The choice matters beyond the order total, because it changes how partial shipments are invoiced, as described in the fulfillment stage below.

Editing rules tighten once explosion has occurred, and this catches users out more than any other behavior in the module. After the kit has exploded, components can no longer be added or deleted from the Component Details popup; only Quantity and Warehouse remain editable there. To add or remove components at that point, users must work with the [X] and [+] buttons on the Document Details tab of the sales order. Before explosion, the picture is different again: if Allow Component Addition is off, new components cannot be added, although existing components can still be deleted.

Stage Five: The Acumatica Kit Assembly Branch

Kit Assembly is an optional branch in the Acumatica data flow rather than a mandatory step, and it is available only when the Kit Assembly feature is enabled on the Enable/Disable Features (CS100000) form. A kit assembly document contains the required stock components with their quantities and costs, calculated according to the kit specification revision you specify. Assemblies can be created directly on the Kit Assembly screen by entering the kit item in the Inventory ID field, selecting the revision, choosing a warehouse, and entering a quantity. Components can be added or removed before the assembly is released.

The more interesting path runs from the sales order, because it lets you assemble without exploding the kit. The user enters the kit on the sales order, optionally adjusts components in the Component Details popup, selects the Mark for Kit Assembly checkbox on the Details tab, and then clicks Generate Kit Assembly from the Actions list followed by Save. The same action is available through the Mark/Unmark for Kit Assembly button in the Component Details dialog. The generated assembly places a link number in the Kit Assembly field on the Details tab of the sales order, and clicking that link opens the Kit Assembly form. The relationship is visible from both ends: the Orders tab of the Kit Assembly screen shows the linked sales order number the assembly came from. Two constraints apply. Kit assemblies generated from sales orders always use the current revision specified on the Kit Specifications screen, and for non-stock kit items the Mark for Assembly button is disabled.

Stage Six: Kit Order Fulfillment in Acumatica

With explosion complete, the order moves into the standard Acumatica fulfillment cycle, and the kit records follow the components rather than the kit. The sequence is four steps. First, click Create Shipment on the toolbar and confirm the Specify Shipment Parameters window with OK. Second, on the Shipments screen to which you are redirected, click Confirm Shipment. Third, on the Invoices screen, click Prepare Invoice. Fourth, release the invoice with the Release button. At that point the inventory and financial impact of the kit is fully posted.

Partial shipments introduce one behavior that finance teams should know before it appears on a customer document. When Use Kit Default Price is the selected price calculation method and the order ships partially, the invoice for the first shipment carries the total kit price, and the invoice price for the remaining items is zero. This is intentional, since the kit is priced once rather than per component, but it looks surprising on a second invoice if nobody was expecting it. Where this is undesirable, Invoice After Full Shipment holds the placeholder back until all components have shipped, so the kit is invoiced only once everything is out the door.

The Purchase Order Side of Kit Processing

Kit Processing in Acumatica is not limited to the sell side. The Purchase Orders Preferences screen carries the same Biz-Tech Kit Processing Settings section, with the same precedence rule that kit-level configuration overrides the general settings, and the same Unexploded Kit Price Calculation by Components and Allow Edit Exploded Kit Component behaviors. Adding a kit item to a purchase order gives access to the same Component Details popup, where components can be added, deleted, or exchanged for substitutes and options can be changed before explosion. The kit is exploded either by clicking Load Components or by assigning a quantity to the kit line, exactly as on the sales order.

The inbound flow then completes in three moves. A purchase order containing the kit items is created and exploded. When the components are received, a purchase receipt for the ordered items is created. On release of that purchase receipt, the system automatically generates an inventory receipt reflecting the items in inventory. That automatic inventory receipt is the point at which purchased kit components become available stock, so it is the record to check when component availability does not look right after a delivery.

Where the Flow Starts Earlier: Opportunities and Sales Quotes

For businesses that quote before they sell, the kit data flow begins one step earlier. A kit item is added on the Details tab of the Opportunities screen and a quote is generated with the Create Quote button. The kit will not explode on the Opportunities screen itself.

Explosion happens on the Sales Quotes screen, either by giving the kit a quantity or by clicking Load Components on the Details tab. After saving, the exploded kit is reflected back in the Details tab of the Opportunities screen, and from then on any change made to the exploded kit updates in both screens. This is also the path where Default Code earns its place, since no user is prompted to pick options during automated or quote-driven creation.

Kit Pricing Summary: Where Pricing Is Reviewed and Applied

Kit Pricing Summary is the analysis point of the Acumatica Kit Processing flow, and it uses the same explosion logic as the order screens. For a kit to appear here, its specification must have the Active checkbox selected and the Revision field filled in. Selecting the kit in the Kit Inventory ID field loads the kit together with its components, stock components first and non-stock components after. Each component line displays Quantity, Unit Price, Min Markup %, Markup %, Extended Price, and Surcharge, and the calculated totals of Extended Price and Surcharge appear on the last line.

Two formulas govern the numbers. Surcharge is calculated as quantity multiplied by unit price multiplied by minimum markup, divided by one hundred. Total with Surcharge is the sum of the extended price and surcharge amounts across the component lines. Clicking Apply Price takes the total surcharge from the last line and applies it to the kit item's default price, which is how component-level markup becomes a kit-level price. The screen works for nested kits as well: after the parent kit is exploded, the components of both kits load together and the totals line sums their extended prices and surcharges. The whole summary can be exported to Excel, which makes it a practical review artifact for a pricing meeting.

Where to Monitor Kit Processing Results in Acumatica

If you are training users or troubleshooting a kit order in Acumatica, these are the fields and screens that tell you what the system actually did:

• Current Revision on Kit Specifications, which determines the revision every downstream document reads.
• Explode Option and Explode Kit, which decide whether the order line ever becomes components.
• Block Kit Items Explosion on the Customers, Vendors, and Order Types screens, which silently overrides the kit's own explode setting.
• Total Cost of Components on the kit placeholder row, which carries the frozen unit cost forward to the invoice.
• PO Number in the Component Details popup, which confirms whether a component was purchased and stays accurate if the purchase order is deleted.
• Kit Assembly on the sales order Details tab, which links to the generated assembly, and the Orders tab of the Kit Assembly screen, which links back.
• The Component Availability section of Component Details, which can display Qty. Available, Qty. Avail. for Shipping, and Qty. on Hand.
• Next receive information in the same window, including next receive type and reference number, with Inc. In Receipt, Inc. In Transfer, Inc. PO, Inc. PO Receipt, and Inc. PO Transfer controlling which documents are considered when calculating the next receive date and quantity.
• The totals line on Kit Pricing Summary, where extended price and surcharge are reviewed before Apply Price changes the kit's default price.

One note on availability display: if any kit component has a quantity of zero and the kit item is not set to back order allowed, an error message appears when the availability checkbox is selected. That message is a genuine signal about allocation, not a display fault.

Loading Kits in Bulk with Acumatica Import Scenarios

Kit items do not have to be built by hand. Acumatica import scenarios support structured, automated entry of kit data from external sources, and the product ships with a set of scenarios that map to the stages described above. BZ-Import Is a Kit Check Box in Non-Stock and BZ-Import Is a Kit Check Box in Stock enable the Is a Kit checkbox on the respective item forms, which is the prerequisite for everything else. BZ-Import Kit Header configures the header section of the Kit Specifications screen. BZ-Import Kit Stock Components and BZ-Import Kit Non-Stock Components add components to the kit. BZ-Import Kit Option Category adds option categories, option codes, and the stock and non-stock components associated with each code, and BZ-Import Kit Substitution adds substitute items for the relevant components. Before running any of them, confirm that data mapping between the external source and the corresponding Acumatica fields is correct, and remember that Default Code matters here because an import has no user to answer an options prompt.

Kit Processing in Acumatica: Frequently Asked Questions

What is the kit placeholder item and why does Acumatica use one?

The kit placeholder item is a non-stock item that replaces the kit item on the Sales Orders screen after explosion. Because the components are added to the order as their own lines, keeping the original kit item would double-count item cost. The placeholder behaves like the kit item in the order but contains no actual items. Its unit of measure must match the unit of measure of the kit item, or the system raises a warning.

Why will my kit not explode on the sales order?

Check four things in order. The kit specification must have Explode Kit selected and a current revision marked. The Explode Option must not be set to Do Not Explode. The Block Kit Items Explosion checkbox may be selected on the Customers or Vendors screen, or in the Biz-Tech Kit Processing Settings on the Order Types screen, either of which prevents explosion. Finally, Unexploded Kit Price Calculation by Components deliberately prevents explosion and prices the kit by its components instead.

Can components be changed after a kit has exploded?

Only partially. Once the kit has exploded, components can no longer be added or deleted from the Component Details popup, where just Quantity and Warehouse remain editable. To add or remove components after explosion, use the [X] and [+] buttons on the Document Details tab of the sales order. Editing component quantities and deleting components on the order screen also requires Allow Edit Exploded Kit Component to be enabled in preferences.

How does Acumatica price a kit that ships partially?

When Use Kit Default Price is the selected price calculation method, the invoice for the first shipment carries the total kit price and the invoice price for the remaining items is zero, because the kit is priced once rather than per component. If you would rather invoice only when the order is complete, enable Invoice After Full Shipment, which permits partial shipment but holds the placeholder item back until every component has shipped.

Can a kit contain another kit?

Yes. Kit items can be configured as nested components or options inside both stock and non-stock kit specifications, with the outer kit acting as the Parent Kit and the included kit as the Child Kit. If a non-stock kit is used as a component or option, the Explode Option for both the parent and the child must be set to Automatically. The Copy Kit function and the Kit Pricing Summary screen both support nested kits.

How do I create a purchase order for a single kit component?

Add the kit to the sales order and, without exploding it, open the Component Details popup. Select the Mark for PO checkbox for the component you need and click Create PO. The required quantity must have a value. The purchase order is created against the component's Default Vendor ID, several components sharing a vendor are combined into one purchase order, and the resulting number appears in the PO Number field of the popup.

Work With the Biz-Tech Services Kit Processing Product

Kit Processing in Acumatica rewards teams who understand the flow rather than memorizing screens. The specification defines the kit, preferences supply the defaults, order entry shapes the line, explosion turns one line into a placeholder plus components, and fulfillment converts those components into shipments, invoices, and inventory transactions. Once users know which field governs each handoff and where to look when a result is unexpected, kit orders stop being a special case and become routine.

If your business sells or purchases configured products and wants kit components visible and controllable right on the order, we are glad to help you scope, configure, and roll out Kit Processing. Visit https://biz-techservices.com to learn more about our Acumatica expertise or to schedule a personalized demonstration of the Biz-Tech Services Kit Processing product.

How Kit Processing Works in Acumatica from Order Entry to Fulfillment

Kit Processing in Acumatica is easiest to understand as a data flow rather than as a screen. A single kit record starts life on the Kit Specifications form, picks up defaults from your preferences screens, becomes a line on a sales order, splits into a placeholder and a set of components, and finally resolves into a shipment, an invoice, and a set of inventory transactions. Every problem a user ever reports with kits traces back to one of those handoffs. Understanding where each record is created, which field controls the next step, and where the result becomes visible is what makes the module predictable.

The Biz-Tech Services Kit Processing product lets users explode kit components directly on the Sales Orders screen, with no need to open a separate maintenance form or print a pick list just to see what a kit contains. Cost calculation for kit items is controlled from the native Sales Order Preferences screen, which gives companies flexibility without forcing maintenance adjustments to inventory items. This article follows a kit through the entire Acumatica data flow, from the specification that defines it to the released invoice that closes it out, and points out the fields worth watching at each stage.

Stage One: The Kit Specification Is the Source of Every Record

Everything downstream inherits from the Kit Specifications form, so this is where the data flow begins. The form is available only when the Kit Assembly feature is enabled on the Enable/Disable Features (CS100000) form, and you can create a kit specification only for an inventory item that has already been marked as a kit on the General tab of the Stock Items (IN202500) or Non-Stock Items (IN202000) form. That marking is the true origin point of the record. Without it, no specification can exist.

The header fields define the identity of the kit. Kit Inventory ID is the inventory identifier of the kit as assigned on the stock or non-stock item form, and Non-Stock is a read-only checkbox indicating that the kit is a non-stock kit. Revision ID uniquely identifies each revision of the specification, and Description holds a brief summary. Two checkboxes govern whether the record participates in the flow at all: Active marks the specification as usable, and Current Revision indicates which revision the system will actually use when the kit explodes on a sales order. If a kit item already has a current revision and you attempt to change it, the system warns you that saving will uncheck the previous one. Only one revision is current at a time, and that is the revision the rest of the flow will read.

Explode Kit is the field that determines whether the kit will break into its components on the Sales Orders screen. Selecting it activates three further fields that shape the entire downstream flow: Kit Placeholder Item, Explode Option, and Price Calculation. Kit has options adds Option Category and Option Codes tabs, where you define the choices a user will be asked to make during order entry. Marking an option category as Required forces the user to select a code in the Options popup before the kit order can proceed, while Sort Order controls whether categories appear in ascending or descending order in the Sales Orders dropdown. Default Code automatically includes an option code in the order without user input, which matters a great deal for any path where no human is present to choose: API calls, import scenarios, processing screens, and opportunities or sales quotes.

Three further checkboxes extend what users can change later in the flow. Allow Option Rules adds an Option Rule tab, where a source option category and code exclude a target option category and code on the Sales Orders screen. If Size 8x10 is configured to exclude the color Black, a user who selects 8x10 will not be offered Black; selecting a size that is not covered by a rule, such as 8x12, makes Black available again. Allow Component Substitution adds a Substitution tab and a matching column on the Stock Components tab, letting you nominate replacement items for specific components. Allow Component Addition activates the Add Row option in the Component Details dialog on the Sales Orders screen, permitting new components to be added before the kit explodes.

Two structural rules belong here because they cause real problems when missed. First, the Unit of Measure of the Kit Placeholder Item must match the Unit of Measure of the kit item, or the system raises a warning. Second, for nested kits, where a kit item is used as a component or option inside another kit, the main kit is the Parent Kit and the included kit is the Child Kit. If a non-stock kit is used as a component or option, the Explode Option for both the parent and the child must be set to Automatically. The same requirement applies when a non-stock kit contains a stock option item, because only automatic explosion ensures the stock option is allocated during shipment.

Stage Two: Acumatica Preferences Supply the Defaults That Flow Downstream

The second stage of the Acumatica Kit Processing data flow is the Biz-Tech Services Kit Processing Settings section on the Sales Orders Preferences screen, with an equivalent section on the Purchase Orders Preferences screen. Price Calculation for Kits, Kit Placeholder Item, and Explode Option are general settings that apply to every kit. The precedence rule is simple and worth teaching to every user: if those same settings are configured manually for a specific kit on the Kit Specifications screen, the system prioritizes the kit-level setting over the general one. When a kit behaves differently from what preferences suggest, the specification is almost always the reason. If the specific item has already configyration done in Kit Specifications screen, then the setup of individual item would be used

Several preference fields change how quantities and documents behave later in the flow. Not Calculate Component Quantities bases quantity calculation in sales orders on the quantity specified for the kit itself. Invoice After Full Shipment allows partial shipment and holds the placeholder item back until every component has shipped. Use Kit Posting Group places the kit item's account and subaccount values on the placeholder row after explosion, and Apply to the Components extends those same values to the component rows. Allow Kit Assembly Generation enables the assembly branch described later. Unexploded Kit Price Calculation by Components prevents the kit from exploding and calculates only the price of the components toward the order total, which is why selecting it triggers a warning that the Explode Kit checkbox should be unchecked.

Components Qty. Is Required for Kit Item Ship deserves particular attention, because it decides whether a shipment can be created at all. Selecting it reveals a dropdown with three shipping behaviors. Ship Available Qty. sets the kit or placeholder line to back order allowed and lets a shipment be created for the minimum component quantity, without requiring every component to be available. Ship Ordered Qty. requires all components to be available and allocated based on the kit quantity, so nothing ships until everything is ready. The third option allows back order without requiring component quantity to be available for shipping. Finally, Allow Edit Exploded Kit Component gives users control over component quantities after explosion and permits deletion of kit components on the Sales Orders screen, and it has the same effect on the Purchase Orders screen when set in purchase order preferences.

Two settings outside these screens can also stop the flow. Selecting Block Kit Items Explosion on the Customers or Vendors screen prevents kits from exploding for that business account, and the same checkbox in the Biz-Tech Kit Processing Settings on the Order Types screen prevents explosion for that order type. Both override the explode option on the kit itself, so they are the first place to look when a kit refuses to explode for one customer or one order type but works everywhere else.

Stage Three: Sales Order Entry and the Component Details Window

Once a kit item is added to a sales order, the flow moves into the Component Details popup, which is the working surface for everything that happens before explosion. If the kit has options, an Options popup opens automatically when the kit item is entered, prompting the user to select an option code for each option category before pressing OK. Those selections can still be revised without exploding the kit by using the Change Options button in Component Details; all previous option category and option code configurations remain intact unless they are manually changed.

Before explosion, Component Details is where the order line is shaped. Users can add or delete components, and they can exchange a component for an approved substitute by double-clicking the item and choosing the replacement from the search icon that appears beside it. This window is also the point where purchasing can be triggered. Selecting the Mark for PO checkbox for a component and clicking Create PO generates a purchase order, and the resulting purchase order number is displayed under the PO Number field in Component Details. The required quantity must have a value for the purchase order to be created. Purchase orders are created according to the Default Vendor ID of each component, and when several components share the same vendor, a single purchase order covers them all. If that purchase order or its lines are later deleted, the number is removed from Component Details automatically, which keeps the reference trustworthy.

Stage Four: Acumatica Kit Explosion and the Placeholder Item

Explosion is the pivotal transformation in the Biz-Tech Services Acumatica Kit Processing flow, because it is the moment one order line becomes many. A kit explodes in one of two ways: by clicking Load Components in the Component Details dialog, or simply by assigning a quantity to the newly added kit on the sales order. Which of these is even possible depends on the Explode Option chosen earlier. Prompt asks the user whether to explode, Automatically explodes without user intervention, and Do Not Explode prevents explosion entirely.

When the kit explodes, the kit placeholder item and its components appear on the sales order lines with their respective prices, quantities, and costs. The placeholder is a non-stock item that replaces the kit item on the Sales Orders screen after explosion. Its purpose is financial accuracy: a kit item consists of multiple components, and when those components are added to the order as real lines, leaving the original kit item in place would double-count item cost. The placeholder behaves like the kit item in the order but contains no actual items. One field on that placeholder row is worth monitoring closely. Total Cost of Components is calculated as the component's unit cost at the time the sales order was created, which does not change afterward, multiplied by the quantity. It is displayed on the kit placeholder row and carried forward to the invoice, making it the natural checkpoint for verifying kit margin.

Price Calculation determines what the customer is charged, and it offers three methods. Use Kit Default Price applies the kit's own default price, plus any manually added price for its options. Use Component Default Price bases the price on each component's default price and sets the kit item price to zero. Use Combined Default Price adds the kit's default price to the default prices of the components. The choice matters beyond the order total, because it changes how partial shipments are invoiced, as described in the fulfillment stage below.

Editing rules tighten once explosion has occurred, and this catches users out more than any other behavior in the module. After the kit has exploded, components can no longer be added or deleted from the Component Details popup; only Quantity and Warehouse remain editable there. To add or remove components at that point, users must work with the [X] and [+] buttons on the Document Details tab of the sales order. Before explosion, the picture is different again: if Allow Component Addition is off, new components cannot be added, although existing components can still be deleted.

Stage Five: The Acumatica Kit Assembly Branch

Kit Assembly is an optional branch in the Acumatica data flow rather than a mandatory step, and it is available only when the Kit Assembly feature is enabled on the Enable/Disable Features (CS100000) form. A kit assembly document contains the required stock components with their quantities and costs, calculated according to the kit specification revision you specify. Assemblies can be created directly on the Kit Assembly screen by entering the kit item in the Inventory ID field, selecting the revision, choosing a warehouse, and entering a quantity. Components can be added or removed before the assembly is released.

The more interesting path runs from the sales order, because it lets you assemble without exploding the kit. The user enters the kit on the sales order, optionally adjusts components in the Component Details popup, selects the Mark for Kit Assembly checkbox on the Details tab, and then clicks Generate Kit Assembly from the Actions list followed by Save. The same action is available through the Mark/Unmark for Kit Assembly button in the Component Details dialog. The generated assembly places a link number in the Kit Assembly field on the Details tab of the sales order, and clicking that link opens the Kit Assembly form. The relationship is visible from both ends: the Orders tab of the Kit Assembly screen shows the linked sales order number the assembly came from. Two constraints apply. Kit assemblies generated from sales orders always use the current revision specified on the Kit Specifications screen, and for non-stock kit items the Mark for Assembly button is disabled.

Stage Six: Kit Order Fulfillment in Acumatica

With explosion complete, the order moves into the standard Acumatica fulfillment cycle, and the kit records follow the components rather than the kit. The sequence is four steps. First, click Create Shipment on the toolbar and confirm the Specify Shipment Parameters window with OK. Second, on the Shipments screen to which you are redirected, click Confirm Shipment. Third, on the Invoices screen, click Prepare Invoice. Fourth, release the invoice with the Release button. At that point the inventory and financial impact of the kit is fully posted.

Partial shipments introduce one behavior that finance teams should know before it appears on a customer document. When Use Kit Default Price is the selected price calculation method and the order ships partially, the invoice for the first shipment carries the total kit price, and the invoice price for the remaining items is zero. This is intentional, since the kit is priced once rather than per component, but it looks surprising on a second invoice if nobody was expecting it. Where this is undesirable, Invoice After Full Shipment holds the placeholder back until all components have shipped, so the kit is invoiced only once everything is out the door.

The Purchase Order Side of Kit Processing

Kit Processing in Acumatica is not limited to the sell side. The Purchase Orders Preferences screen carries the same Biz-Tech Kit Processing Settings section, with the same precedence rule that kit-level configuration overrides the general settings, and the same Unexploded Kit Price Calculation by Components and Allow Edit Exploded Kit Component behaviors. Adding a kit item to a purchase order gives access to the same Component Details popup, where components can be added, deleted, or exchanged for substitutes and options can be changed before explosion. The kit is exploded either by clicking Load Components or by assigning a quantity to the kit line, exactly as on the sales order.

The inbound flow then completes in three moves. A purchase order containing the kit items is created and exploded. When the components are received, a purchase receipt for the ordered items is created. On release of that purchase receipt, the system automatically generates an inventory receipt reflecting the items in inventory. That automatic inventory receipt is the point at which purchased kit components become available stock, so it is the record to check when component availability does not look right after a delivery.

Where the Flow Starts Earlier: Opportunities and Sales Quotes

For businesses that quote before they sell, the kit data flow begins one step earlier. A kit item is added on the Details tab of the Opportunities screen and a quote is generated with the Create Quote button. The kit will not explode on the Opportunities screen itself.

Explosion happens on the Sales Quotes screen, either by giving the kit a quantity or by clicking Load Components on the Details tab. After saving, the exploded kit is reflected back in the Details tab of the Opportunities screen, and from then on any change made to the exploded kit updates in both screens. This is also the path where Default Code earns its place, since no user is prompted to pick options during automated or quote-driven creation.

Kit Pricing Summary: Where Pricing Is Reviewed and Applied

Kit Pricing Summary is the analysis point of the Acumatica Kit Processing flow, and it uses the same explosion logic as the order screens. For a kit to appear here, its specification must have the Active checkbox selected and the Revision field filled in. Selecting the kit in the Kit Inventory ID field loads the kit together with its components, stock components first and non-stock components after. Each component line displays Quantity, Unit Price, Min Markup %, Markup %, Extended Price, and Surcharge, and the calculated totals of Extended Price and Surcharge appear on the last line.

Two formulas govern the numbers. Surcharge is calculated as quantity multiplied by unit price multiplied by minimum markup, divided by one hundred. Total with Surcharge is the sum of the extended price and surcharge amounts across the component lines. Clicking Apply Price takes the total surcharge from the last line and applies it to the kit item's default price, which is how component-level markup becomes a kit-level price. The screen works for nested kits as well: after the parent kit is exploded, the components of both kits load together and the totals line sums their extended prices and surcharges. The whole summary can be exported to Excel, which makes it a practical review artifact for a pricing meeting.

Where to Monitor Kit Processing Results in Acumatica

If you are training users or troubleshooting a kit order in Acumatica, these are the fields and screens that tell you what the system actually did:

• Current Revision on Kit Specifications, which determines the revision every downstream document reads.
• Explode Option and Explode Kit, which decide whether the order line ever becomes components.
• Block Kit Items Explosion on the Customers, Vendors, and Order Types screens, which silently overrides the kit's own explode setting.
• Total Cost of Components on the kit placeholder row, which carries the frozen unit cost forward to the invoice.
• PO Number in the Component Details popup, which confirms whether a component was purchased and stays accurate if the purchase order is deleted.
• Kit Assembly on the sales order Details tab, which links to the generated assembly, and the Orders tab of the Kit Assembly screen, which links back.
• The Component Availability section of Component Details, which can display Qty. Available, Qty. Avail. for Shipping, and Qty. on Hand.
• Next receive information in the same window, including next receive type and reference number, with Inc. In Receipt, Inc. In Transfer, Inc. PO, Inc. PO Receipt, and Inc. PO Transfer controlling which documents are considered when calculating the next receive date and quantity.
• The totals line on Kit Pricing Summary, where extended price and surcharge are reviewed before Apply Price changes the kit's default price.

One note on availability display: if any kit component has a quantity of zero and the kit item is not set to back order allowed, an error message appears when the availability checkbox is selected. That message is a genuine signal about allocation, not a display fault.

Loading Kits in Bulk with Acumatica Import Scenarios

Kit items do not have to be built by hand. Acumatica import scenarios support structured, automated entry of kit data from external sources, and the product ships with a set of scenarios that map to the stages described above. BZ-Import Is a Kit Check Box in Non-Stock and BZ-Import Is a Kit Check Box in Stock enable the Is a Kit checkbox on the respective item forms, which is the prerequisite for everything else. BZ-Import Kit Header configures the header section of the Kit Specifications screen. BZ-Import Kit Stock Components and BZ-Import Kit Non-Stock Components add components to the kit. BZ-Import Kit Option Category adds option categories, option codes, and the stock and non-stock components associated with each code, and BZ-Import Kit Substitution adds substitute items for the relevant components. Before running any of them, confirm that data mapping between the external source and the corresponding Acumatica fields is correct, and remember that Default Code matters here because an import has no user to answer an options prompt.

Kit Processing in Acumatica: Frequently Asked Questions

What is the kit placeholder item and why does Acumatica use one?

The kit placeholder item is a non-stock item that replaces the kit item on the Sales Orders screen after explosion. Because the components are added to the order as their own lines, keeping the original kit item would double-count item cost. The placeholder behaves like the kit item in the order but contains no actual items. Its unit of measure must match the unit of measure of the kit item, or the system raises a warning.

Why will my kit not explode on the sales order?

Check four things in order. The kit specification must have Explode Kit selected and a current revision marked. The Explode Option must not be set to Do Not Explode. The Block Kit Items Explosion checkbox may be selected on the Customers or Vendors screen, or in the Biz-Tech Kit Processing Settings on the Order Types screen, either of which prevents explosion. Finally, Unexploded Kit Price Calculation by Components deliberately prevents explosion and prices the kit by its components instead.

Can components be changed after a kit has exploded?

Only partially. Once the kit has exploded, components can no longer be added or deleted from the Component Details popup, where just Quantity and Warehouse remain editable. To add or remove components after explosion, use the [X] and [+] buttons on the Document Details tab of the sales order. Editing component quantities and deleting components on the order screen also requires Allow Edit Exploded Kit Component to be enabled in preferences.

How does Acumatica price a kit that ships partially?

When Use Kit Default Price is the selected price calculation method, the invoice for the first shipment carries the total kit price and the invoice price for the remaining items is zero, because the kit is priced once rather than per component. If you would rather invoice only when the order is complete, enable Invoice After Full Shipment, which permits partial shipment but holds the placeholder item back until every component has shipped.

Can a kit contain another kit?

Yes. Kit items can be configured as nested components or options inside both stock and non-stock kit specifications, with the outer kit acting as the Parent Kit and the included kit as the Child Kit. If a non-stock kit is used as a component or option, the Explode Option for both the parent and the child must be set to Automatically. The Copy Kit function and the Kit Pricing Summary screen both support nested kits.

How do I create a purchase order for a single kit component?

Add the kit to the sales order and, without exploding it, open the Component Details popup. Select the Mark for PO checkbox for the component you need and click Create PO. The required quantity must have a value. The purchase order is created against the component's Default Vendor ID, several components sharing a vendor are combined into one purchase order, and the resulting number appears in the PO Number field of the popup.

Work With the Biz-Tech Services Kit Processing Product

Kit Processing in Acumatica rewards teams who understand the flow rather than memorizing screens. The specification defines the kit, preferences supply the defaults, order entry shapes the line, explosion turns one line into a placeholder plus components, and fulfillment converts those components into shipments, invoices, and inventory transactions. Once users know which field governs each handoff and where to look when a result is unexpected, kit orders stop being a special case and become routine.

If your business sells or purchases configured products and wants kit components visible and controllable right on the order, we are glad to help you scope, configure, and roll out Kit Processing. Visit https://biz-techservices.com to learn more about our Acumatica expertise or to schedule a personalized demonstration of the Biz-Tech Services Kit Processing product.

---

by Gary

ServiceTitan Acumatica Integration Configuration Checklist

ServiceTitan Acumatica Integration Configuration Checklist

A successful ServiceTitan Acumatica integration is decided long before the first invoice ever crosses between the two systems. It is decided during configuration. Field service companies live in two platforms at once: dispatchers, technicians, and sales staff work inside ServiceTitan every hour of the day capturing jobs, invoices, purchase orders, and payments in the field, while the controller and accounting team depend on Acumatica to manage inventory, branches, vendors, and the general ledger. When those two systems are not connected, the result is predictable. The same invoice gets keyed twice, purchase receipts pile up waiting to be reconciled, and nobody can say with confidence what a job actually cost.

The Biz-Tech Services ServiceTitan Connector closes that gap so the work recorded in the field lands in your Enterprise Resource Planning, or ERP, system exactly once and exactly right. A connector, however, is only as reliable as the configuration behind it, and the most common cause of a rough go-live is not the software but a mapping that was never completed or a date filter that was never set. This ServiceTitan Acumatica integrator configuration checklist walks through every required setting, the data you need to prepare in advance, the points where you should stop and validate, the user access to confirm, and the tests to run before you switch on automatic synchronization.

Step One: Configure the ServiceTitan Store in Acumatica

Every ServiceTitan Acumatica integration begins with the ServiceTitan Store. This is the single most important step in the entire setup process and it belongs on the first line of your checklist. The Store is the foundation on which every other setting depends, because it controls your invoice import rules, your customer creation rules, your inventory and item handling, your warehouse and branch mapping, your vendor and business unit mapping, your transaction processing logic, and the way purchase orders, receipts, and bills flow into Acumatica. If the ServiceTitan Store is not configured correctly, the system will not work and no data can be imported at all.

Start by assigning a Store Code, the lookup value that identifies the corresponding ServiceTitan store, and give it a clear Description so your team can recognize it later. If you select the Default Store checkbox, will tell the system to set and display that store code automatically on every processing screen, removing a small but repetitive step from your users' daily routine. Companies operating several stores should decide up front which one carries the default flag.

With the Store record in place, move to the General Settings tab and enter the credentials generated on the ServiceTitan side to authorize the connection. Once those values are saved, use the Test Credentials action before going any further. This validation step confirms that Acumatica can reach your ServiceTitan store through the Application Programming Interface, or API, and it is the earliest safe point to catch a mistyped key or an authorization that was never granted. Do not begin any mapping work until this test succeeds.

Step Two: Set Invoice, Tax, and Payment Import Options

The next item on the ServiceTitan integration checklist is the Import Options tab, where your business decides what actually comes across. Selecting the Activate Invoice checkbox opens the invoice section and lets you import invoices along with their taxes, payment methods, customer data, and general ledger accounts. You will need to specify the Invoice Type, which determines what kind of document ServiceTitan invoices become in Acumatica, and choose whether to import invoices with one preferred status or with all statuses at once.

Date filtering deserves particular attention during preparation, because it governs how much history you pull in on day one. The Begin Invoice Date defines the point from which the first import should reach back, and the Last Invoice Date records when the most recent import ran, which subsequent import processes then use as their starting point. Choose your beginning date deliberately. Setting it too far back can pull years of closed transactions into a fresh system, while setting it too late can leave open invoices stranded in ServiceTitan.

Tax handling is a simple checkbox that enables importing invoices with their taxes included, but confirm with your accounting team that the resulting tax treatment matches how they expect revenue to post. For payments, selecting the Activate Payment checkbox allows invoices to arrive with their payment information attached. Two decisions follow. First, the Payment Type determines whether payments imported from ServiceTitan are created in Acumatica as payments or as prepayments. Second, Release Payment After Import controls whether those payments are released automatically or left for your team to review. Many businesses leave automatic release turned off during the first few weeks and enable it once they trust the results.

Step Three: Prepare Customer, Country, Term, and GL Account Data

How your business handles customer records is the next preparation point, and it has real consequences for the cleanliness of your Acumatica database. If the Import Customer checkbox is left unselected, every invoice arrives assigned to a single default customer. If it is selected, the connector creates the customer in Acumatica whenever that customer is missing, using the default customer class you nominate. Decide which model fits your operation before go-live, and if you choose automatic creation, make sure the default customer class is configured with the correct general ledger accounts, terms, and statement settings, because every new customer will inherit them.

Address handling is controlled separately. The Override Bill Address Information from Invoice and Override Ship Address Information from Invoice checkboxes allow the customer's billing and shipping addresses to be imported into Acumatica from the invoice itself. Enable these when the field-captured address should be treated as authoritative. Alongside addresses, review the Country Options, since country names are passed to Acumatica in International Organization for Standardization, or ISO, country code format. Note that when the Activate Payment checkbox is selected, the Country options become hidden, so plan your review of this section accordingly.

Two mapping tables round out this stage of the ServiceTitan Acumatica setup. Term Options aligns ServiceTitan term values with the corresponding Acumatica terms, and Account Options maps ServiceTitan general ledger accounts to your Acumatica chart of accounts. Complete both with your controller in the room. An unmapped term or GL account is the kind of gap that does not surface until the first import run, and by then it is already producing exceptions.

Step Four: Configure Inventory Items and Transaction Settings

Inventory preparation is where most of the pre-launch data work lives. When the Import Item checkbox is selected, the Generate Item from ServiceTitan option becomes available, and the connector will create non-stock and stock items in Acumatica based on the Stock Item Class, Non-Stock Item Class, and Unit of Measure values you designate. Those three values are prerequisites, so confirm they exist and are correctly configured before enabling generation. Your business can also skip automatic creation entirely and map ServiceTitan items to existing Acumatica items by hand, which is often the better path for companies with a mature, curated item master.

Use the Load Materials, Load Equipment, Load Services action to retrieve the corresponding ServiceTitan items and display them on the Inventory tab, and understand the rule the system applies: Materials and Equipment become stock items, while Services become non-stock items. Reviewing that list before go-live is one of the highest-value validation steps on this checklist, because it is your last comfortable opportunity to spot duplicates, retired parts, or items that should never have been synchronized.

On the Transactions tab, configure each transaction type your business actually uses. Receipts, Transfers, Adjustments, and Returns each have their own setup options, along with a corresponding Release Receipt After Import, Release Transfer After Import, Release Adjustment After Import, and Release Return After Import checkbox. Selecting a release checkbox means those documents are imported into Acumatica and released in the same pass. The Activate Bill checkbox on this tab allows bills to be imported together with their receipts. As with payments, we generally recommend leaving automatic release unselected for the first cycle so your team can inspect the documents in a balanced state before they post.

Step Five: Map Business Units, Warehouses, PO Types, and Vendors

The Biz-Tech Services Service Titan Acumatica connector needs to know how your ServiceTitan structure corresponds to your Acumatica structure, and these mappings are mandatory. Begin with Business Units, where ServiceTitan Business Unit identifiers are mapped to Acumatica branches. Pressing Load Business Units retrieves the available ServiceTitan values so your team can pair them manually with the correct branch. Get this right and every imported document lands in the correct branch for reporting. Get it wrong and your branch profitability numbers will be wrong from day one.

Warehouses follow the same pattern. The Warehouses tab maps Acumatica warehouses to ServiceTitan Warehouse and Truck identifiers, and the Load Warehouses action retrieves those values for manual pairing. Because trucks are treated as inventory locations, this mapping is what makes technician van stock visible and accurate in your ERP, so give it real attention rather than treating it as a formality.

Finally, complete the purchasing mappings. The PO Types tab maps ServiceTitan purchase receipt order type names to Acumatica purchase order types, and Load PO Types retrieves the available values. Return Types maps ServiceTitan return types to the corresponding Acumatica purchase order types. On the Vendors tab, selecting the Import Vendor checkbox lets the connector create ServiceTitan vendors in Acumatica, while Load Vendors retrieves the full vendor list from ServiceTitan so your team can map existing vendors manually instead. For most established businesses, manual mapping of your top vendors combined with automatic creation for the long tail strikes the right balance.

Step Six: Import ServiceTitan Purchase Orders, Receipts, and Bills in Order

This section of the checklist is less about a setting and more about a rule your team must understand, because it is the single most common source of go-live confusion in a ServiceTitan Acumatica integration. The Purchase Order module workflow requires that ServiceTitan purchase receipts and bills cannot be imported into Acumatica unless the related ServiceTitan purchase order has already been imported. Sequence matters, and it is not negotiable.

Purchase orders are brought in through the Import ServiceTitan Purchase Orders screen and are created in Acumatica as purchase orders, retrieved based on their updated date. If a ServiceTitan purchase receipt or bill already exists at the moment the purchase order is imported, it comes across in the same process. If the receipt or bill does not yet exist in ServiceTitan, it is simply not imported, and it can be brought over later through its own screen once it has been created. Before importing purchase orders at all, confirm that the required preferences have been configured on the ServiceTitan Stores screen, since the import depends on them.

The Import Receipts screen retrieves purchase order receipts based on the date and status defined in your Receipt Options, and it can be run manually or automatically through the scheduler. If a receipt is imported before its purchase order exists in Acumatica, the system stops and returns a message such as POOrder document for Receipt 433272225 has not been created yet. That message is not a defect. It is the sequencing rule protecting your data. When the purchase order is already present, the connector locates it and attaches the receipt document to the PO History tab of the Purchase Orders screen. The receipt arrives with a Released status if the release checkbox is selected in the store setup, and with a balanced status if it is not. Where a receipt includes a bill, that bill is imported in the same pass and attached to the same PO History tab.

Bills follow identical logic on the Import ServiceTitan Bills screen, retrieved by their updated date. A bill cannot be imported on its own without its corresponding purchase order, and attempting to do so produces an error. If you import a purchase order while its related bill is sitting on the processing screen, the bill is imported alongside it and disappears from that screen. If the purchase order was imported earlier, importing the bill later automatically locates the parent document and attaches it. One additional field belongs on your configuration checklist here: the Branch For Bills field, which applies specifically when bills are imported and Bills and Adjustments documents are created in Acumatica.

Step Seven: Validate ServiceTitan Invoice and Payment Import

Before you declare go-live readiness, run a controlled test of the invoice and payment path, because there are three distinct scenarios and your team should recognize all of them. Invoices are retrieved on the Import SO Invoices screen based on their updated date and the statuses you selected. In the first scenario, an invoice that already carries a payment at the moment it is retrieved is imported together with that payment. The invoice is created on the Invoices and Memos screen, the payment is created and applied under the Applications tab of that invoice, and the corresponding payment identifier disappears from the Import Invoice Payments screen because it has already been processed.

In the second scenario, the invoice has already been imported but the payment is still waiting on the processing screen. Here the connector locates the matching invoice during the payment import and applies the payment automatically. The third scenario is the reverse: the payment was taken first and the invoice is imported afterward, in which case the system matches the two on its own. The Import Invoice Payments screen retrieves all payments from ServiceTitan and shows the associated Invoice ID, and payments can be imported separately, either as a deposit or after the invoice already exists. In every case the outcome is the same, which is that the payment ends up matched to the correct invoice in Acumatica. Test all three paths with real data in a sandbox tenant before go-live and your finance team will know exactly what they are looking at on launch day.

Step Eight: Journal Entries, Scheduling, and User Access

If your business intends to bring journal entries across rather than invoices, activate the Journal Entry checkbox on the Import Options tab while the Activate Invoice checkbox is disabled. Pay close attention to one detail that catches teams out: the Begin Journal Entry Date is not set automatically the first time, so a user must enter it manually. The Last Journal Entry Date then records the most recent import, and you should also define which statuses qualify for import. Put this on the checklist explicitly, because an unset beginning date is a silent failure rather than a visible error.

Turning to operations, decide how synchronization will run. Every processing screen can be executed manually or automatically through the Acumatica scheduler, and documents are retrieved based on their updated date. We recommend running manually for the first several cycles so your team sees each batch before it posts, then moving to a scheduled cadence once the results are consistently clean. Confirm at the same time that user access is correct. The staff responsible for each processing screen need the appropriate Acumatica roles, and the ServiceTitan credentials used by the connector should belong to a dedicated integration account rather than an individual employee whose access might be revoked.

ServiceTitan Acumatica Integration Checklist: Quick Reference

Before you launch, walk through this final go-live readiness checklist with your project team:

• The ServiceTitan Store is created, the Default Store flag is set, and Test Credentials returns a successful result.
• Invoice type, import statuses, and the Begin Invoice Date are configured to match your intended cutover point.
• Customer creation, default customer class, and address override behavior reflect an agreed policy.
• Term and general ledger account mappings are complete and reviewed by your controller.
• Item classes and unit of measure values exist, and the loaded ServiceTitan item list has been inspected.
• Business units, warehouses and trucks, purchase order types, return types, and vendors are all mapped.
• The Branch For Bills field is set if your business imports bills.
• Your team understands that purchase orders must be imported before receipts and bills.
• All three invoice and payment scenarios have been tested in a sandbox environment.
• Release-after-import options are set deliberately, and the scheduler plan is agreed.
• Acumatica roles are assigned, and the connector uses a dedicated ServiceTitan integration account.

ServiceTitan Acumatica Integration FAQ

What is the first step in setting up a ServiceTitan Acumatica integration?

Configuring the ServiceTitan Store is always the first step. The Store controls invoice import rules, customer creation, inventory handling, warehouse and branch mapping, vendor and business unit mapping, and the purchase order workflow. Until the Store is set up and Test Credentials returns a successful result, no data can be imported into Acumatica.

Can ServiceTitan receipts and bills be imported without the purchase order?

No. ServiceTitan purchase receipts and bills cannot be imported into Acumatica unless the related purchase order has already been imported. Attempting to import a receipt first produces an error message identifying the missing purchase order document. Import purchase orders first, and any receipt or bill that already exists in ServiceTitan will come across in the same process.

Does the connector create customers and vendors in Acumatica automatically?

It can. Selecting the Import Customer checkbox creates a customer in Acumatica whenever one is missing, using your default customer class. Selecting the Import Vendor checkbox does the same for vendors. If you prefer tighter control, leave these unselected and use a default customer, or map ServiceTitan vendors to existing Acumatica vendors manually with the Load Vendors action.

How are ServiceTitan items created in Acumatica?

When Import Item is selected, the Generate Item from ServiceTitan option creates items using your Stock Item Class, Non-Stock Item Class, and Unit of Measure values. Materials and Equipment become stock items, while Services become non-stock items. You can also map ServiceTitan items to existing Acumatica items manually instead of generating them.

How are ServiceTitan payments matched to Acumatica invoices?

Three scenarios are handled automatically. If the invoice carries a payment when it is retrieved, both import together and the payment is applied under the Applications tab. If the invoice was imported earlier, the payment import locates it and applies the payment. If the payment was taken first, the system matches it when the invoice arrives. In all three cases the payment ends up applied to the correct invoice.

Can the ServiceTitan Acumatica integration run automatically?

Yes. Every processing screen can run manually or on a schedule through the Acumatica scheduler, with documents retrieved by their updated date. We recommend running manually for the first several cycles so your team can review each batch, then switching to a scheduled cadence once results are consistently clean.

Get Started With the ServiceTitan Acumatica Connector

The Biz-Tech Services ServiceTitan Acumatica Connector is built for field service businesses that need their operational reality and their financial records to agree without anyone retyping a thing. Purchase orders, receipts, bills, invoices, payments, inventory transactions, and journal entries all flow into Acumatica along a defined path, and the quality of that flow is determined by the configuration work you complete before you begin. Working through this ServiceTitan Acumatica integration checklist methodically is what separates a launch that quietly succeeds from one that consumes weeks of cleanup.

If your business is preparing to connect ServiceTitan to Acumatica, we are glad to help at every stage, from initial scoping through configuration, validation, and go-live support. Visit https://biz-techservices.com to learn more about our integration expertise or to schedule a personalized demonstration of the Biz-Tech Services ServiceTitan Acumatica Connector.

SEO Metadata (for the publisher, remove before posting)

Focus keyword: ServiceTitan Acumatica integration

Secondary keywords: ServiceTitan Acumatica connector; ServiceTitan integration checklist; ServiceTitan Acumatica setup; import ServiceTitan invoices into Acumatica; ServiceTitan purchase order import; field service ERP integration; ServiceTitan Stores configuration

SEO title (58 characters): ServiceTitan Acumatica Integration Configuration Checklist

Meta description (154 characters): Complete pre-launch configuration checklist for the ServiceTitan Acumatica integration: store setup, mappings, imports, validation, and go-live readiness.

URL slug: servicetitan-acumatica-integration-configuration-checklist

Suggested internal links: ServiceTitan Connector product page; Acumatica integrations overview; Salesforce Acumatica Integration Configuration Checklist

Schema markup: Article plus FAQPage. The FAQ section is written for FAQ rich results.

Image alt text: Set on all seven images inside this document; carries over on paste into a CMS.

ServiceTitan Acumatica Integration Configuration Checklist

A successful ServiceTitan Acumatica integration is decided long before the first invoice ever crosses between the two systems. It is decided during configuration. Field service companies live in two platforms at once: dispatchers, technicians, and sales staff work inside ServiceTitan every hour of the day capturing jobs, invoices, purchase orders, and payments in the field, while the controller and accounting team depend on Acumatica to manage inventory, branches, vendors, and the general ledger. When those two systems are not connected, the result is predictable. The same invoice gets keyed twice, purchase receipts pile up waiting to be reconciled, and nobody can say with confidence what a job actually cost.

The Biz-Tech Services ServiceTitan Connector closes that gap so the work recorded in the field lands in your Enterprise Resource Planning, or ERP, system exactly once and exactly right. A connector, however, is only as reliable as the configuration behind it, and the most common cause of a rough go-live is not the software but a mapping that was never completed or a date filter that was never set. This ServiceTitan Acumatica integrator configuration checklist walks through every required setting, the data you need to prepare in advance, the points where you should stop and validate, the user access to confirm, and the tests to run before you switch on automatic synchronization.

Step One: Configure the ServiceTitan Store in Acumatica

Every ServiceTitan Acumatica integration begins with the ServiceTitan Store. This is the single most important step in the entire setup process and it belongs on the first line of your checklist. The Store is the foundation on which every other setting depends, because it controls your invoice import rules, your customer creation rules, your inventory and item handling, your warehouse and branch mapping, your vendor and business unit mapping, your transaction processing logic, and the way purchase orders, receipts, and bills flow into Acumatica. If the ServiceTitan Store is not configured correctly, the system will not work and no data can be imported at all.

Start by assigning a Store Code, the lookup value that identifies the corresponding ServiceTitan store, and give it a clear Description so your team can recognize it later. If you select the Default Store checkbox, will tell the system to set and display that store code automatically on every processing screen, removing a small but repetitive step from your users' daily routine. Companies operating several stores should decide up front which one carries the default flag.

With the Store record in place, move to the General Settings tab and enter the credentials generated on the ServiceTitan side to authorize the connection. Once those values are saved, use the Test Credentials action before going any further. This validation step confirms that Acumatica can reach your ServiceTitan store through the Application Programming Interface, or API, and it is the earliest safe point to catch a mistyped key or an authorization that was never granted. Do not begin any mapping work until this test succeeds.

Step Two: Set Invoice, Tax, and Payment Import Options

The next item on the ServiceTitan integration checklist is the Import Options tab, where your business decides what actually comes across. Selecting the Activate Invoice checkbox opens the invoice section and lets you import invoices along with their taxes, payment methods, customer data, and general ledger accounts. You will need to specify the Invoice Type, which determines what kind of document ServiceTitan invoices become in Acumatica, and choose whether to import invoices with one preferred status or with all statuses at once.

Date filtering deserves particular attention during preparation, because it governs how much history you pull in on day one. The Begin Invoice Date defines the point from which the first import should reach back, and the Last Invoice Date records when the most recent import ran, which subsequent import processes then use as their starting point. Choose your beginning date deliberately. Setting it too far back can pull years of closed transactions into a fresh system, while setting it too late can leave open invoices stranded in ServiceTitan.

Tax handling is a simple checkbox that enables importing invoices with their taxes included, but confirm with your accounting team that the resulting tax treatment matches how they expect revenue to post. For payments, selecting the Activate Payment checkbox allows invoices to arrive with their payment information attached. Two decisions follow. First, the Payment Type determines whether payments imported from ServiceTitan are created in Acumatica as payments or as prepayments. Second, Release Payment After Import controls whether those payments are released automatically or left for your team to review. Many businesses leave automatic release turned off during the first few weeks and enable it once they trust the results.

Step Three: Prepare Customer, Country, Term, and GL Account Data

How your business handles customer records is the next preparation point, and it has real consequences for the cleanliness of your Acumatica database. If the Import Customer checkbox is left unselected, every invoice arrives assigned to a single default customer. If it is selected, the connector creates the customer in Acumatica whenever that customer is missing, using the default customer class you nominate. Decide which model fits your operation before go-live, and if you choose automatic creation, make sure the default customer class is configured with the correct general ledger accounts, terms, and statement settings, because every new customer will inherit them.

Address handling is controlled separately. The Override Bill Address Information from Invoice and Override Ship Address Information from Invoice checkboxes allow the customer's billing and shipping addresses to be imported into Acumatica from the invoice itself. Enable these when the field-captured address should be treated as authoritative. Alongside addresses, review the Country Options, since country names are passed to Acumatica in International Organization for Standardization, or ISO, country code format. Note that when the Activate Payment checkbox is selected, the Country options become hidden, so plan your review of this section accordingly.

Two mapping tables round out this stage of the ServiceTitan Acumatica setup. Term Options aligns ServiceTitan term values with the corresponding Acumatica terms, and Account Options maps ServiceTitan general ledger accounts to your Acumatica chart of accounts. Complete both with your controller in the room. An unmapped term or GL account is the kind of gap that does not surface until the first import run, and by then it is already producing exceptions.

Step Four: Configure Inventory Items and Transaction Settings

Inventory preparation is where most of the pre-launch data work lives. When the Import Item checkbox is selected, the Generate Item from ServiceTitan option becomes available, and the connector will create non-stock and stock items in Acumatica based on the Stock Item Class, Non-Stock Item Class, and Unit of Measure values you designate. Those three values are prerequisites, so confirm they exist and are correctly configured before enabling generation. Your business can also skip automatic creation entirely and map ServiceTitan items to existing Acumatica items by hand, which is often the better path for companies with a mature, curated item master.

Use the Load Materials, Load Equipment, Load Services action to retrieve the corresponding ServiceTitan items and display them on the Inventory tab, and understand the rule the system applies: Materials and Equipment become stock items, while Services become non-stock items. Reviewing that list before go-live is one of the highest-value validation steps on this checklist, because it is your last comfortable opportunity to spot duplicates, retired parts, or items that should never have been synchronized.

On the Transactions tab, configure each transaction type your business actually uses. Receipts, Transfers, Adjustments, and Returns each have their own setup options, along with a corresponding Release Receipt After Import, Release Transfer After Import, Release Adjustment After Import, and Release Return After Import checkbox. Selecting a release checkbox means those documents are imported into Acumatica and released in the same pass. The Activate Bill checkbox on this tab allows bills to be imported together with their receipts. As with payments, we generally recommend leaving automatic release unselected for the first cycle so your team can inspect the documents in a balanced state before they post.

Step Five: Map Business Units, Warehouses, PO Types, and Vendors

The Biz-Tech Services Service Titan Acumatica connector needs to know how your ServiceTitan structure corresponds to your Acumatica structure, and these mappings are mandatory. Begin with Business Units, where ServiceTitan Business Unit identifiers are mapped to Acumatica branches. Pressing Load Business Units retrieves the available ServiceTitan values so your team can pair them manually with the correct branch. Get this right and every imported document lands in the correct branch for reporting. Get it wrong and your branch profitability numbers will be wrong from day one.

Warehouses follow the same pattern. The Warehouses tab maps Acumatica warehouses to ServiceTitan Warehouse and Truck identifiers, and the Load Warehouses action retrieves those values for manual pairing. Because trucks are treated as inventory locations, this mapping is what makes technician van stock visible and accurate in your ERP, so give it real attention rather than treating it as a formality.

Finally, complete the purchasing mappings. The PO Types tab maps ServiceTitan purchase receipt order type names to Acumatica purchase order types, and Load PO Types retrieves the available values. Return Types maps ServiceTitan return types to the corresponding Acumatica purchase order types. On the Vendors tab, selecting the Import Vendor checkbox lets the connector create ServiceTitan vendors in Acumatica, while Load Vendors retrieves the full vendor list from ServiceTitan so your team can map existing vendors manually instead. For most established businesses, manual mapping of your top vendors combined with automatic creation for the long tail strikes the right balance.

Step Six: Import ServiceTitan Purchase Orders, Receipts, and Bills in Order

This section of the checklist is less about a setting and more about a rule your team must understand, because it is the single most common source of go-live confusion in a ServiceTitan Acumatica integration. The Purchase Order module workflow requires that ServiceTitan purchase receipts and bills cannot be imported into Acumatica unless the related ServiceTitan purchase order has already been imported. Sequence matters, and it is not negotiable.

Purchase orders are brought in through the Import ServiceTitan Purchase Orders screen and are created in Acumatica as purchase orders, retrieved based on their updated date. If a ServiceTitan purchase receipt or bill already exists at the moment the purchase order is imported, it comes across in the same process. If the receipt or bill does not yet exist in ServiceTitan, it is simply not imported, and it can be brought over later through its own screen once it has been created. Before importing purchase orders at all, confirm that the required preferences have been configured on the ServiceTitan Stores screen, since the import depends on them.

The Import Receipts screen retrieves purchase order receipts based on the date and status defined in your Receipt Options, and it can be run manually or automatically through the scheduler. If a receipt is imported before its purchase order exists in Acumatica, the system stops and returns a message such as POOrder document for Receipt 433272225 has not been created yet. That message is not a defect. It is the sequencing rule protecting your data. When the purchase order is already present, the connector locates it and attaches the receipt document to the PO History tab of the Purchase Orders screen. The receipt arrives with a Released status if the release checkbox is selected in the store setup, and with a balanced status if it is not. Where a receipt includes a bill, that bill is imported in the same pass and attached to the same PO History tab.

Bills follow identical logic on the Import ServiceTitan Bills screen, retrieved by their updated date. A bill cannot be imported on its own without its corresponding purchase order, and attempting to do so produces an error. If you import a purchase order while its related bill is sitting on the processing screen, the bill is imported alongside it and disappears from that screen. If the purchase order was imported earlier, importing the bill later automatically locates the parent document and attaches it. One additional field belongs on your configuration checklist here: the Branch For Bills field, which applies specifically when bills are imported and Bills and Adjustments documents are created in Acumatica.

Step Seven: Validate ServiceTitan Invoice and Payment Import

Before you declare go-live readiness, run a controlled test of the invoice and payment path, because there are three distinct scenarios and your team should recognize all of them. Invoices are retrieved on the Import SO Invoices screen based on their updated date and the statuses you selected. In the first scenario, an invoice that already carries a payment at the moment it is retrieved is imported together with that payment. The invoice is created on the Invoices and Memos screen, the payment is created and applied under the Applications tab of that invoice, and the corresponding payment identifier disappears from the Import Invoice Payments screen because it has already been processed.

In the second scenario, the invoice has already been imported but the payment is still waiting on the processing screen. Here the connector locates the matching invoice during the payment import and applies the payment automatically. The third scenario is the reverse: the payment was taken first and the invoice is imported afterward, in which case the system matches the two on its own. The Import Invoice Payments screen retrieves all payments from ServiceTitan and shows the associated Invoice ID, and payments can be imported separately, either as a deposit or after the invoice already exists. In every case the outcome is the same, which is that the payment ends up matched to the correct invoice in Acumatica. Test all three paths with real data in a sandbox tenant before go-live and your finance team will know exactly what they are looking at on launch day.

Step Eight: Journal Entries, Scheduling, and User Access

If your business intends to bring journal entries across rather than invoices, activate the Journal Entry checkbox on the Import Options tab while the Activate Invoice checkbox is disabled. Pay close attention to one detail that catches teams out: the Begin Journal Entry Date is not set automatically the first time, so a user must enter it manually. The Last Journal Entry Date then records the most recent import, and you should also define which statuses qualify for import. Put this on the checklist explicitly, because an unset beginning date is a silent failure rather than a visible error.

Turning to operations, decide how synchronization will run. Every processing screen can be executed manually or automatically through the Acumatica scheduler, and documents are retrieved based on their updated date. We recommend running manually for the first several cycles so your team sees each batch before it posts, then moving to a scheduled cadence once the results are consistently clean. Confirm at the same time that user access is correct. The staff responsible for each processing screen need the appropriate Acumatica roles, and the ServiceTitan credentials used by the connector should belong to a dedicated integration account rather than an individual employee whose access might be revoked.

ServiceTitan Acumatica Integration Checklist: Quick Reference

Before you launch, walk through this final go-live readiness checklist with your project team:

• The ServiceTitan Store is created, the Default Store flag is set, and Test Credentials returns a successful result.
• Invoice type, import statuses, and the Begin Invoice Date are configured to match your intended cutover point.
• Customer creation, default customer class, and address override behavior reflect an agreed policy.
• Term and general ledger account mappings are complete and reviewed by your controller.
• Item classes and unit of measure values exist, and the loaded ServiceTitan item list has been inspected.
• Business units, warehouses and trucks, purchase order types, return types, and vendors are all mapped.
• The Branch For Bills field is set if your business imports bills.
• Your team understands that purchase orders must be imported before receipts and bills.
• All three invoice and payment scenarios have been tested in a sandbox environment.
• Release-after-import options are set deliberately, and the scheduler plan is agreed.
• Acumatica roles are assigned, and the connector uses a dedicated ServiceTitan integration account.

ServiceTitan Acumatica Integration FAQ

What is the first step in setting up a ServiceTitan Acumatica integration?

Configuring the ServiceTitan Store is always the first step. The Store controls invoice import rules, customer creation, inventory handling, warehouse and branch mapping, vendor and business unit mapping, and the purchase order workflow. Until the Store is set up and Test Credentials returns a successful result, no data can be imported into Acumatica.

Can ServiceTitan receipts and bills be imported without the purchase order?

No. ServiceTitan purchase receipts and bills cannot be imported into Acumatica unless the related purchase order has already been imported. Attempting to import a receipt first produces an error message identifying the missing purchase order document. Import purchase orders first, and any receipt or bill that already exists in ServiceTitan will come across in the same process.

Does the connector create customers and vendors in Acumatica automatically?

It can. Selecting the Import Customer checkbox creates a customer in Acumatica whenever one is missing, using your default customer class. Selecting the Import Vendor checkbox does the same for vendors. If you prefer tighter control, leave these unselected and use a default customer, or map ServiceTitan vendors to existing Acumatica vendors manually with the Load Vendors action.

How are ServiceTitan items created in Acumatica?

When Import Item is selected, the Generate Item from ServiceTitan option creates items using your Stock Item Class, Non-Stock Item Class, and Unit of Measure values. Materials and Equipment become stock items, while Services become non-stock items. You can also map ServiceTitan items to existing Acumatica items manually instead of generating them.

How are ServiceTitan payments matched to Acumatica invoices?

Three scenarios are handled automatically. If the invoice carries a payment when it is retrieved, both import together and the payment is applied under the Applications tab. If the invoice was imported earlier, the payment import locates it and applies the payment. If the payment was taken first, the system matches it when the invoice arrives. In all three cases the payment ends up applied to the correct invoice.

Can the ServiceTitan Acumatica integration run automatically?

Yes. Every processing screen can run manually or on a schedule through the Acumatica scheduler, with documents retrieved by their updated date. We recommend running manually for the first several cycles so your team can review each batch, then switching to a scheduled cadence once results are consistently clean.

Get Started With the ServiceTitan Acumatica Connector

The Biz-Tech Services ServiceTitan Acumatica Connector is built for field service businesses that need their operational reality and their financial records to agree without anyone retyping a thing. Purchase orders, receipts, bills, invoices, payments, inventory transactions, and journal entries all flow into Acumatica along a defined path, and the quality of that flow is determined by the configuration work you complete before you begin. Working through this ServiceTitan Acumatica integration checklist methodically is what separates a launch that quietly succeeds from one that consumes weeks of cleanup.

If your business is preparing to connect ServiceTitan to Acumatica, we are glad to help at every stage, from initial scoping through configuration, validation, and go-live support. Visit https://biz-techservices.com to learn more about our integration expertise or to schedule a personalized demonstration of the Biz-Tech Services ServiceTitan Acumatica Connector.

SEO Metadata (for the publisher, remove before posting)

Focus keyword: ServiceTitan Acumatica integration

Secondary keywords: ServiceTitan Acumatica connector; ServiceTitan integration checklist; ServiceTitan Acumatica setup; import ServiceTitan invoices into Acumatica; ServiceTitan purchase order import; field service ERP integration; ServiceTitan Stores configuration

SEO title (58 characters): ServiceTitan Acumatica Integration Configuration Checklist

Meta description (154 characters): Complete pre-launch configuration checklist for the ServiceTitan Acumatica integration: store setup, mappings, imports, validation, and go-live readiness.

URL slug: servicetitan-acumatica-integration-configuration-checklist

Suggested internal links: ServiceTitan Connector product page; Acumatica integrations overview; Salesforce Acumatica Integration Configuration Checklist

Schema markup: Article plus FAQPage. The FAQ section is written for FAQ rich results.

Image alt text: Set on all seven images inside this document; carries over on paste into a CMS.

---

by Gary

Salesforce Acumatica Integration Configuration Checklist

Salesforce Acumatica Integration Configuration Checklist

In many fast-growing companies, an invisible wall often exists between the sales team and the finance department. Your sales representatives live and breathe in their Customer Relationship Management, or CRM, platform to close deals, while your accounting and operations teams rely on their Enterprise Resource Planning, or ERP, system to manage inventory and billing. When these two worlds do not talk to each other, your business suffers from manual data entry, duplicate records, and a lack of real-time visibility into customer health. We at Biz-Tech Services know that bridging the gap between Salesforce and Acumatica is not just a technical task, but a strategic move to streamline your entire order-to-cash cycle.

The Biz-Tech Services Salesforce Acumatica Connector is a robust integrator designed to ensure data flows smoothly between these two powerful platforms. It provides a comprehensive solution for synchronizing customer data, automating complex workflows, and maintaining accurate financial reporting. To help your business prepare for a successful integration, we have developed a practical configuration checklist that covers everything from technical foundations to go-live readiness.

The Essential Technical Foundation

The first step in your configuration journey is ensuring your system meets the basic requirements for the Biz-Tech Services SalesForce Acumatica integration. Before we begin the setup, your business must have the correct license installed on your Acumatica system, such as a Software as a Service, or SAAS, or a Perpetual license. Once the license is in place, the primary technical task is establishing a secure link through the Application Programming Interface.

You will need to gather several key pieces of information from your Salesforce instance to facilitate this connection. First, you must identify your specific instance URL and the Username and Password for the integrator account. Second, you will need a Client ID and a Client Secret, which act as the digital keys for the Biz-Tech Services SalesForce Acumatica integrator. After entering these credentials into the general information area, we use the actions feature to Test Credentials. This validation step confirms the correctness of the login details and ensures the two systems can communicate before any data begins to move.

Defining Your Order and Customer Logic

Once the technical bridge is built, your business must decide how information should be organized as it enters your ERP. The first item on this part of the checklist is defining your Default Import Options. You must select a specific order type to indicate which document category the Salesforce orders should land in, and assign a default warehouse identification number to ensure your inventory is tracked correctly. We also recommend setting a beginning date for your first import to ensure the system only retrieves the records you are ready to process.

The second consideration is how the system should handle Customer records. You have the option to enable an import customer feature that automatically creates new customer records in Acumatica during the order import process. This automated creation includes the customer's email, contact information, and assigned customer class. If you choose not to enable this, the system can be configured to use a default customer record for every imported order instead. Additionally, you must decide if the Biz-Tech Services SalesForce Acumatica integration should override existing billing and shipping address information with the data provided in the Salesforce order, ensuring your shipments always reach the correct destination.

Mapping Data with Cross-References and Items

For the Biz-Tech Services SalesForce Acumatica integration to be truly seamless, the two systems must speak the same language regarding shipping and payments. This is where cross-reference options become critical. First, you must create mappings for common fields like payment methods, countries, and Ship Via services. For example, if a salesperson selects a specific shipping carrier in Salesforce, the cross-reference ensures the correct internal shipping code is applied in Acumatica.

Second, your business must prepare its inventory data. You can enable a feature on Ityem Settings tab that creates new items in your ERP based on information from Salesforce. If this is not enabled, the system will search for an existing inventory identification by using the Salesforce product Stock Keeping Unit, or SKU.

If the product does not already exist in your ERP, the system will display an error message to prevent data discrepancies. Here we have already performed Sync All From SalesFore process and got Stock Items created

Third, we look at tax options. You can choose to use your internal tax categories or enable an External Tax calculation service, such as Avalara, to handle complex tax requirements automatically.

Managing Prices, Discounts, and Payments

A vital part of your go-live readiness is ensuring your pricing and promotions are synchronized. The Biz-Tech Services SalesForce Acumatica connector allows your business to manage price books directly. You can retrieve all existing items from a Salesforce price book and display them within your ERP, allowing you to manually define or update list prices as needed. It is important to remember that items must be included in your standard price book before they can be added to any specialized price books.

Furthermore, the checklist should include your promotional strategies. When you configure discount codes in your ERP, they can be exported to Salesforce for use during the order creation process. These discounts can be applied at either the individual line level or the overall document level. Finally, you must define your default payment options. You can choose to release payments automatically during the import process or skip the payment step if you prefer to handle billing as a separate financial task.

Validation and Real-Time Synchronization

As you move toward your launch date, testing the Sync Orders to Salesforce feature is essential. This capability allows your team to update imported order data within Acumatica — such as changing a shipping address or adding a new line item — and then process those changes back to Salesforce. This ensures that your sales team always sees the most current information regarding an order's total, tax, and freight amounts. The system even retrieves internal notes from Salesforce and displays them in the sales order notes area of your ERP, though these are kept uneditable to maintain the integrity of the original sales record.

This Biz-Tech Services SalesForce Acumatica integrator is built for modern enterprises that need to eliminate the data gap between their front-office sales activities and their back-office financial functions. By following this structured configuration checklist, we ensure that your teams can make informed decisions based on up-to-date, synchronized information.

If you are ready to streamline your order processing and improve visibility across your entire organization, we are here to help you every step of the way. We invite you to visit https://biz-techservices.com to learn more about our integration expertise or to schedule a personalized demo of the Biz-Tech Services Salesforce Acumatica Connector.

---

by Gary