Skip to main content
Avalara Help Center

ZZ Schedules, Transactions and Scenarios

This article applies to:Excise
This document applies to Enterprise license.  Content last updated 8/3/2017 
Help Center documentation is confidential and proprietary to Avalara clients
ZZ refers to custom schedules and transaction reporting.  
  • ZZ Schedule is a schedule code that does not affect a tax return.
    • ZZ Default Custom is the name of the schedule code built into the software for every tax session.
    • ZZ Custom Schedule is one created by the user.
  • ZZ Transaction is a transaction record that was unassigned to a jurisdiction's schedule code in the import process.  
    • It can also be a transaction assigned to a ZZ Schedule.
  • ZZ Scenario is a scenario that assigns a transaction to a custom schedule code.
    • Default ZZ Schedule captures transactions that are unassigned
    • Non-Default  Scenario is one that is user-created, and assigns a transaction to a custom ZZ Schedule.
ZZ schedules can also be entered through import or manual entry when you want to enter records associated with the tax session, but not reported to the jurisdiction.  There is one ZZ schedule for each taxpayer type and jurisdiction.  

Use in import troubleshooting

When your record count in schedule transactions is less than the import file, query the ZZ Schedules. This is commonly referred to by sent to ZZ.  You can manually correct ZZ records or use the Query Wizard.

Example of ZZ schedule assignment

A jurisdiction requires you to report disbursements outside of the US on schedule 7A, but not the exact place of delivery.  In this case, you have a fuel delivery to Mexico.  The record reported to the jurisdiction says only that it is an international destination.  You can also enter it on a custom ZZ record named ZZ7A in that same tax session showing that it went to a licensed distributor in Guadalajara.  Now when you query schedule code names that contain 7A, it will show you both records.

Manually enter a ZZ transaction

  1. From the Tax Filing Schedule Transactions menu, select ZZ: Default Custom to use the default schedule.  
  2. Custom schedule codes that you added will appear in the dropdown list.
  3. There are no required fields on ZZ, but the choices from the dropdown lists must be first entered in corresponding the table.

Creating a ZZ custom schedule

You can create your own custom schedules.  

  1. Click Maintenance > Custom Schedules.
  2. Click Add New Record.
  3. All the fields on the General tab are required.
  4. The schedule code must start with the letters ZZ and can be any transaction type.
  5. You must choose a specific taxpayer type for the record you add.
    • You can also use this same schedule code on additional taxpayer types.
  6. Set an effective date that is prior to the period in which the record will be reported.
    • For instance, if you are filing for period beginning 4/1/2014 the effective date must be 3/31/2014 or earlier.
  7. Sort order is where the returns will list the schedule relative to the other schedules.
  8. Click Insert to save the record.
    Note: Custom ZZ schedules do not have product validation, so a product code is not included in the record criteria.
  9. Click the Columns tab.
  10. Click  the fields to display in the Schedule Transactions menu.
  11. Click the arrow to add it to the Field Name list.
  12. Click the pencil icon to edit the properties of the field.
  13. Click the check mark to save the edits.

Import a ZZ transaction

Records can imported to either the default ZZ schedule or a custom schedule.  They can be either assigned a schedule name or by using scenarios.

  1. Default Option uses Fallout schedule.  Fallout is a term used by Avalara Professional Services for a custom schedule that is intended to go on a tax return, but does not.  It's a catch-all so that unassigned records don't get lost.
  2. Custom Schedules do not have product validation so the Validate Products option must always be set to NO.

Creating Non-Default Scenarios

  1. Creating a non-default scenario for a Custom Schedule Code sets up custom reporting. 
  2. Scenario/schedule combinations can be used to create specific reports for transactions already on a return.  
    • Example: show all clear kerosene sold tax free for heating purposes. 
  3. Capture transactions that are in the data but are being ignored due to that particular state’s regulations .
    • Example: all dyed diesel transactions in states where it is not reportable.
  4. Use multiple scenarios to send all transactions to one single schedule code (like a normal scenario) or you can create multiple combinations of scenarios and schedules.
TIP:  Use the Comments area in the scenario to describe the logic in configuring it.  Note both what you changed and why for reference. 

Non-Default Scenario Examples

This scenario will capture all transactions that meet the criteria, even if they were also assigned elsewhere. 

  • If this scenario were used on a return where dyed diesel was reportable, the transactions would be duplicated to ZZ for informational purposes. 
  • If it were a jurisdiction where dyed diesel was not reportable, this might be the only place those records are assigned in schedule transactions.
  1. Create your custom ZZ schedule code.
  2. Click Maintenance > Schedule Scenarios.
    • The example is non-reportable dyed diesel for New Hampshire.
  3. Select Add New Record
    • If you prefer, you can copy an existing scenario.
  4. Enter the required fields, indicated by an asterisk (*).
    • The effective date must be later than the custom ZZ schedule code
  5. Add General criteria to your scenario.  
    • The example captures all disbursements with destination=NH
  6. Validate Against Schedule Products and Default are bothset to No.
  7. Click on the Details tab and Add New Record.
  8. Set Default Field to PRODUCT_CODE because there is no product validation on custom schedules.
  9. Set Comparison Operator to Not In.
  10. Set Value to the excluded products, each separated by a comma.  
  11. Click the check mark to save the record.
    • The sales destination is NH so we don't need the Locations tab settings.
    • We don't need the Accounts tab settings, since we are not tracking the seller.

Alternatively, if you had a custom field from the source data that identified dyed products as a group, you could filter by that custom field instead of the product_codes.

Default Scenario examples

Default option scenarios act as Fallout schedules, replacing the unassigned file.  This means that in addition to whatever criteria we add to the scenario, the transaction must also be unassigned at the level specified in the default option.

What the default settings mean

  • Yes – All: Does not compare tax session country code, jurisdiction, or taxpayer type to the scenario’s country code, jurisdiction, or taxpayer type
  • Yes - Target Jurisdiction: Compares transaction’s tax session country code and jurisdiction to the scenario’s country code and jurisdiction.  
  • Yes – Target Taxpayer Type: Compares transaction’s tax session country code, jurisdiction, and taxpayer type to the scenario’s country code, jurisdiction, and taxpayer type.
  • Yes – Location Jurisdiction:  Compares transaction’s origin or destination country code and jurisdiction to the scenario’s country code and jurisdiction.

Default set to Yes scenarios

  1. Default options settings:
  2. Default scenario examples:
    • Global Fallout is the most basic default scenario.
    • Default Option set to Yes-All.
    • Product Validation set to No.
    • Broad jurisdictions criteria - user any jurisdiction.
    • Schedule code needs to be selected for a specific tax return.
  3. State Specific Fallout – Captures transactions that were likely assigned to a particular state, but did not match a scenario. 
  • Use the default option, and then add the location criteria. 
  • A minimum of 2 scenarios is needed to make this method effective.
  • Default Option set to Yes – Jurisdiction.
  • Product Validation set to No.
  • Example A scenario captures any transactions that had a destination state of the target jurisdiction. State equal to State


  • Example B scenario captures any transactions for export.  State not equal to State


Example summary: 

  • These two example scenarios capture any transactions that could possibly be assigned to the  target jurisdiction without duplicating any. 
  • Scenario logic can be customized with additional parameters.  
  • Using 4 scenarios you could capture Receipts and Disbursements separately.  
                                         Alternately, you could default at the return level not the state level.

Scenarios maintenance

As returns become obsolete, also mark as obsolete any scenarios that apply to them.  Scenarios that are attempting to match on returns that are no longer available can cause inconsistencies in your transactions assignments.

  • Was this article helpful?