Tax Forms Processing
2-D Bar Coding Standards

Revision 2010v1
October 31, 2010

---

Technology Standards Page > 2-D Barcode Standards Development > 2010 Final Standard

This 2-D Bar Coding Standards Revision 2010v1document is a Final Version.

Vendor Codes [added October 2009]

NOTE - For any filing for previous years, the appropriate annual-release standards version should be used.

see past year standards

* * * * * * * * * * *

Uniform Practices/Standards

By agreement of all market participants, use of these 2-D Standards (including Appendix 1) is designated mandatory. Our procedure is to continue to discuss appropriate issues as warranted and, where possible, come to agreement on what ought to be raised to the level of a mandatory Standard, based on group consensus.

1. General
One agency point of contact should be established to assist with questions and issues in implementation of 2-D bar coding.

There should also be a second point of contact as a backup for the primary person. 2-D specifications should include a phone, fax, e-mail and physical address for these individuals.

In some situations, an agency will have separate personnel that handle the 2-D approval process for vendor data output submitted, and for vendor substitute forms. Each should be listed, along with information for backups.

2. Forms Design
Agencies should examine their candidate tax form(s) carefully to determine whether 2-D can be used effectively. The agency should design the 2-D enabled tax form; this cannot be the responsibility of a vendor.

Form design should change as little as possible:

1. Regarding capture of tax data for forms where one barcode is insufficient: A "barcode data sheet" approach, or alternatively a barcode per schedule approach, has now been successfully used that permits the capture of greater government-required form data volumes. This approach can be designed for tax forms. See the 2-D Guidance document for descriptions of experience with these approaches. The 2-D government and industry partners have chosen NOT to establish standard(s) for the use of multiple barcodes on tax forms at this point in time, since additional experience is needed to determine best standards practice.
2. Agencies should design a maximum of two versions of the form. One version will be printed in the official tax booklet. Since filers of this version will not be using software, a 2-D barcode will not be printed on this version. The second version will be used by software developers to incorporate a 2-D barcode. This version will comply with the computerized industry standards (http://www.nactp.org/Standards.pdf). If a software developer does not support 2-D barcodes, the area reserved for the barcode would be left blank. Therefore, an  agency may not require a form ID or 1-D barcode in the same space reserved for the 2-D barcode. See illustrations below:

Tax Form PDF Example - Handprint (Official Tax Booklet Version)

Tax Form PDF Example - computer generated (with 2-D Barcode) (Computerized Version - may or may not contain a 2-D barcode)

3. Agencies should designate a place on the form for the 4-digit vendor ID listed in Appendix 1 to be printed in addition to being in the 2-D barcode. This will help agencies to identify the software developer responsible for creating the form and data, or data only, for troubleshooting purposes. It is preferred that the software developer be contacted first by the agency if an issue arises rather than contacting the preparer or taxpayer.
4. There are cases where the company producing the form is different from the company creating the data and 2-D barcode on the form. It is recommended that in these cases an additional space on the form be reserved for the 4-digit vendor ID listed in Appendix 1 for those companies only responsible for creating the form.
5. If feasible, an agency can choose to only use one design for both the official form and the software developer version as long as the design complies with computer industry standards.
6. Agencies may desire to employ a separate address for quicker processing. In consideration of those companies who support more than one software program with the same graphic image, agencies are asked to keep the following guidelines in mind:
1. Agencies that intend to establish a separate address to receive returns containing 2-D barcodes should do so by June 15. This will enable companies to allow for the new address in their planning processes for the upcoming tax season.
2. If the form has a "where to mail your return" area, all applicable addresses for both 2-D and non 2-D returns should be included on the computer generated version of the form. Both 2-D and non 2-D addresses should be included because the same computer generated form will be used by all companies regardless of whether or not they support 2-D.
3. If the addresses are printed on the return, the agency should provide some "educational" language describing use of a 2-D barcode to gain greater compliance among tax practitioners and taxpayers.
   
   An example of how to handle multiple mailing addresses can be found on Delaware's Form 200-01, which reads in part,

"If a 2-D barcode (black and white shaded box) appears in the upper right corner of page 1 of this form, send the return to one of the following addresses" and "If a 2-D barcode (black and white shaded box) DOES NOT appear in the upper right corner of page 1 of this form, send the return to one of the following addresses"

each of which is followed by a listing of pertinent addresses.

7. If the agency chooses not to include all addresses for 2-D and non 2-D returns, or space limitations do not allow all addresses to be printed on the return, the software developer may print only the address that is applicable on the return. Example: If a software developer is implementing 2-D barcodes for an agency, it may print just the 2-D barcode address on the return. If a software developer is not implementing 2-D barcodes for a agency, it may print just the non 2-D barcode address on the return.
   
   NOTE: If an agency chooses to print only the applicable addresses on the return, the agency must provide an alternative option for software developers that cannot comply with this standard. The alternative option must be one of the other options in the standards: printing all addresses on the form with educational language included; or not printing any addresses on the form but rather printing a statement referring the taxpayer to the instructions.
   
   
8. If the agency chooses not to put all addresses on the forms, it is recommended that any specific 2-D only address be included along with the existing address in the printed instructions (preferably in bold print) under the "where to mail your return" area. If there is no "mailing of return" area on the form itself, a reference to the tax form instructions for mailing should be noted:
   
   Please follow the mailing instructions provided by your tax preparer or tax software package.
9. All mailing addresses should be printed in the instructions, preferably with the 2-D barcode address(es) in bold.
10. The National Association of Computerized Tax Processors has established Tax Forms Design Guidelines . These Guidelines should be reviewed well prior to 2-D implementation. Click here to access this information.

This bulleted list contains basic design standards for substitute full-page forms, and vouchers and coupons.

2.a. Paper and Ink

1. paper size = 8-1/2 inches x 11 inches
2. paper printing = single-sided
3. paper weight = 15 to 20-pound bond
4. paper color = white
5. ink = black

2.b. Form Text Design

1. page orientation = portrait
2. lines per vertical inch = 6 (1/6 inch) vertically
3. characters per horizontal inch = 10 (1/10 inch) horizontally
4. margin = 1/2-inch margin on all sides
5. vertical printable area:
6. first line = row 4 for first page and row 5 for subsequent pages (based on 6 lines per vertical inch)
7. last line = row 63 (based on 6 lines per vertical inch)
8. horizontal printable area:
9. first printable space = column 6
10. last printable space = column 80
11. box size = minimum 1/10-inch wide by 1/6-inch high (to print a single "X" or single character inside a box)
12. avoid shading or screens in text areas
13. cannot reproduce reverse letters and numbers (white characters with a black background)
14. cannot reproduce rotated text (no landscape font available)
15. recommended that unique logos and tax agency seals not be used, as many software developers are unable to support bitmap images on their printed forms

2.c. Requirements for Vouchers and Coupons

Size:

1. height = 3-2/3 inches to 5-1/2 inches maximum
2. width = 8-1/2 inches (to avoid vertical cut lines)
3. margins = 1/2 inch around each voucher (even if more than one voucher is on a page, a 1/2 inch margin around each voucher must be maintained)

For payroll applications, please also reference IRS Publications 1141 and 1179.

For more, See NACTP's established guidelines (Tax Forms Design Guidelines) at www.nactp.org.

3. 2-D Barcode Technical Matters

A uniform dynamic link library (DLL) that has application across all agencies and forms is available from agencies that are implementing 2-D bar coding for tax forms. A PDF-417 testing tool and instructions on how to obtain a CD-ROM with additional information on 2-D bar coding are also available. Software developers should contact the agency for which they are developing 2-D capable software for further information.

1. PDF 417 has error detection and correction capabilities. The more error correction is used, the less data can be communicated in the barcode. With respect to data capture, you either get 100% or nothing. Complete barcode read failures are very uncommon. The tax Application Programming Interface (taxAPI) sets parameters for correction/detection. These parameters should be observed and not altered.
2. Based on the experience of previous filing seasons of 2-D barcode use, and due to the low level of deterioration of tax returns (compared to high media-abuse environments) the error correction level in the current market-provided DLL is set to level 4.
3. A general rule that can be used to determine if a printer is capable of producing a 2-D barcode is if the printer can produce a graphic such as an agency seal or business logo, then the printer should be capable of producing a 2-D barcode that can be scanned.
4. Pixel shaving is a technique that produces higher-quality barcodes when printed on lower-quality equipment like inkjet printers. Pixel shaving will result in improved read rates. In the DLL, pixel shaving will always be turned on.
5. Increasing the x (horizontal) dimension of the barcode elements from the minimum of 7.5 mils to the maximum of 25 mils will produce the most readable barcodes, especially on low quality ink/bubble jet printers. Whenever possible, software vendors will create a barcode that uses the largest possible x element value for the given space.
6. Users are advised that stretching or scaling the barcode (via copying the paper media or the like) changes its integrity and worsens readability; it should not be employed.
7. 2-D barcodes should never be rotated. Rotating a 2-D barcode increases processing difficulty and introduces the risk of errors. Since PDF-417 barcodes are read in both the x (horizontal) and y (vertical) directions on a portrait page, rotating them from their natural position can render the barcode unscannable.

3.a. Barcode Size and Placement on the Form

Each agency must define the area of the form in which the 2-D barcode is to be placed. Agencies must specify the maximum rectangular dimensions that will enclose the barcode and the location of that rectangle on the form. Software vendors will generate an appropriate 2-D barcode within the space defined. The rectangle can be of any size. However, software vendors recommend a rectangle that has a 2:1 ratio, that is the width is twice the height, as this allows for the creation of an optimal barcode and therefore will provide the best read rates for the agencies. If an area that has a different width to height ratio is specified, the software vendor will generate a 2-D barcode within the space allotted, however read rates may be reduced.

- The X (horizontal) dimension of the barcode element should range from a minimum of 10 mils to a maximum of 25 mils.

- The minimum Y/X ratio of the barcode element should be 2.

- The minimum error correction code level should be 4.

3.b. Barcode Layout

The data contained in a 2-D barcode can be broken down into three general sections.

1. Header Information

2. Government Specific Data

3. Trailer

Each section is discussed separately below.

3.b.1. Header Information

There is information generic to all barcodes that should be placed first in the barcode data stream. The first two fields in the barcode comprise the header. The fields in the header are variable length and therefore can contain as much or as little data as is necessary. Each field in the barcode is delimited by a single carriage return. This separates each piece of data so it may be efficiently processed. The header information must be consistent among all barcodes and is defined below.

(Note: The symbol <CR> is used to represent a single carriage return character.)

3.b.2. Header Field Definition and Order

Header Version Number - The version number will be incremented each time the standards group alters the physical structure of the 2-D barcode header. This allows intelligence to be applied to processing 2-D barcodes that were created using multiple header formats. By using version numbers, software can correctly interpret 2-D barcode headers whose format has changed across fiscal years or within fiscal years. This field is static for all barcodes and is currently "T1".

Developer Code - A four-digit code used to identify the Software Developer whose application produced the barcode. The purpose of this field is to allow forms to be traced to the vendor producing the 2-D barcode. Software Developer codes are assigned through the NACTP. If you are a company interested in developing a 2-D based tax product offering, contact NACTP at the address listed in Appendix 1 to request an ID. Also see Appendix 1 for a current list of Company IDs.

When a vendor has multiple software products that use the same calculation logic, then one vendor ID should suffice for those software products; if different calculation logic is used by any of that vendor’s software product, that product should be assigned its own ID number for testing and approval.

[These multiple Vendor IDs are for use in the 2-D barcode specification in the “developer code” field, since software companies can support a different vendor code or ID printed on the actual graphic or form for these multiple products. 2-D barcode ID can vary because the developer can set the code by product but the capability is not present for the form template, since not all products use the same form template and the ID code is hard coded on the template.]

3.b.3. Government Specific Data
[These fields are optional -- they can be included by agencies in their specifications, if desired.]

The government Specific Data section immediately follows the Header Section. This is where the government places all the data and or fields it wishes to capture from a form. It is suggested that the following fields be added to the field layout before adding taxpayer data to the barcode data stream. These fields may be useful for your backend process. Include them only if your system requires them.

The following fields are NOT required. Do not include them if your backend process does not use them.

Jurisdiction - An alphanumeric identifier indicating the taxing jurisdiction. Use US Postal Service's official state abbreviations. All Federal tax forms should use the code "US". This field should always be upper case.

Description - An alphanumeric identifier used to describe the form being processed. The identifier can be used to route the barcode information to the correct system for further processing. If no special routing or identification information is needed, the field should be blank. In situations where agencies are processing different forms with the same equipment, it is important to be able to uniquely identify the form before further processing of the barcode information can occur. As agencies add 2-D barcodes to more of their forms, this field will become increasingly important. Remember to always assign a unique value to this field for each form or form set you are processing.

Specification Version - A number that identifies the version of the specifications used to produce the form barcode. These specifications are provided by the jurisdiction processing the form and describe the data layout in the barcode. Draft versions of the specifications are not assigned version numbers. The final version shall be "0", revision thereafter will increase numerically. It is the responsibility of the processing agency to communicate any revisions to final specifications to the software development community at large so that the specification version can be incremented. Software developers must increment the specification version number in the header of any barcode they produce if a new version of specifications is issued by the processing agency.

Software/Form Version - A vendor defined version number that reflects the software and form revision used to produce this barcode. This field can be used to track users that are submitting forms using old software. This indicator should be set once the barcode has been approved and incremented each time there is a change made to either the barcode itself or any fields contained in the barcode. This item will only be incremented when there are changes made that would affect the content of the barcode; it will reflect the current barcode release - it will not necessarily indicate the version number of the software release of the general tax product.  Software developers must include a software/form version indicator of their choosing if the processing agency includes this field in their barcode header specifications. Further, software developers must increment this indicator when there are changes made that would affect the content or formatting of the barcode. Upon incrementing the software/form version indicator, software developers must inform their contact at the processing agency of the new indicator value.

3.b.4. Trailer

The last field in the barcode data stream is the trailer. The trailer is used to indicate the end of data has been reached. A static string of "*EOD*" is used as the trailer value. Checking for the trailer gives the agencies an accurate method for determining if all the data supplied by the vendor was received by the agency. If the trailer value is not the last field in the barcode this indicates a data overflow condition has occurred. The agencies need to process forms where there is more data on the form than will fit in the barcode by other means. How to process forms that overflow the capacity of the 2-D barcode is beyond the scope of this standards document and is left up to government  authorities to determine.

3.b.5. Examples - 2-D barcode data streams

EXAMPLE 1

T1<CR> Header Version Number

1111<CR> Developer Code

IN<CR> Government Specific Data

IT40<CR> Government Specific Data

0<CR> Government Specific Data

.

.

.

*EOD* <CR>

EXAMPLE 2

T1<CR> Header Version Number

9999<CR> Developer Code

CA<CR> Government Specific Data

540_2001<CR> Government Specific Data

1<CR> Government Specific Data

.

.

.

*EOD* <CR>

Additional technical guidance on PDF417 can be obtained from the Association for Information Management at www.aimusa.org.

4. File Format
Data Flow

The barcode can contain any taxpayer-entered data that appears on the printed form. The printed form refers to the return as it would ordinarily be submitted to the government agency.

1. Agencies should make their 2-D specifications follow as closely as possible their print form specifications, and make the field formats consistent with them.
2. However, keep any field lengths designed to contain any captured federal data consistent with E-filing specifications.
3. Taxpayer-entered data that does not appear on the printed form should not be included in the barcode. Examples of this would be (1) Direct Deposit information that does not appear on the printed form; and (2) pennies, which are entered by taxpayers but not included on the printed form.
4. Data that is necessary for machine processing and is not taxpayer-entered, such as a form separator, may be included in the barcode. This data would be the same for all taxpayers and will be hard-coded in the barcode record.
5. Late tax form changes - in addition, any changes late in the software development season -that is, after October 1 - to a 2-D enabled form specification should be added at the end of the data layout, to simplify the software industry developer's task in coping with them. Then, during the development period prior to the next filing season, data fields can be re-ordered according to the form layout.
6. Federal return data, other than 1099 and W-2 information, cannot be captured in a state tax return barcode. State agencies wishing to capture Federal information should include it on their own forms/schedules.
7. Agencies may optionally include calculated fields in the barcode, if desired, but they are not required to do so, as they can be re-calculated after the 2-D barcode has been read.
8. Supporting Statements - A supporting statement is an attachment to a tax return that is required by the agency but is created by the tax software without a specific form. Official forms and schedules supported and created by the agency, W2s and 1099s are not considered supporting statements. Because the data from supporting statements creates a risk of exceeding the data size limits of the barcodes, agencies that require them should not include data from those statements in their 2-D barcode specifications.

Example: An example of a supporting statement is a listing of dependents. If there are only four lines on the main tax return to enter dependent information, and the actual number of dependents is six, a separate list must be attached to the return and is considered a supporting statement.

4.a. FIELD FORMAT TABLE

Print vs. 2-D Barcode

This chart outlines the treatment of data fields for print vs. 2-D barcode formatting, and is included here for reference purposes. It is offered to illustrate the differences between print format and 2-D barcode data.

As a general rule the field lengths of 2-D barcode data should never exceed that of the printed form. Agencies need not make changes to their forms for 2-D data capture unless they specifically wish to alter the data captured from their printed forms.

In general, when developing specifications for the 2-D barcode, use the current printed form standards already in place for the form in question as pertaining to the physical appearance of the form.

The fields listed below are those that commonly appear on forms. NOTE: This list of common fields will be added to as additional tax applications are implemented by taxing jurisdictions.

Fields not appearing in the table, that are determined after discussion with the 2-D Standards group to be specific to a particular agency, should be defined in that agency's specifications.

Regarding the data that is captured for the barcode, all non-essential data, commas, whitespace, leading zeros, should be removed.

NOTE:

All delimiters should be stripped in the barcode.

The examples given represent the MAXIMUM field lengths allowable.

DESCRIPTION			PRINT FORMAT		2-D BARCODE FORMAT
Dollar Amounts	Individual Returns		999,999,999. -99,999,999. 12 positions		999999999 -99999999 (significant digits only) 9 positions
	Business Returns		99,999,999,999. -9,999,999,999. 15 positions		99999999999 -9999999999 (significant digits only) 11 positions
	Payroll Forms		999,999,999.99 -99,999,999.99 14 positions		99999999999 -9999999999 (cents should be included; decimal point is assumed) 11 positions
Dates	Date without Century		XX/XX/XX 8 positions		XXXXXX 6 positions
	Date with Century		XX/XX/XXXX 10 positions		XXXXXXXX 8 positions
Taxpayer Info	Taxpayer Name		35 positions		35 positions
	SpouseName		35 positions		35 positions
	In Care Of		35 positions		35 positions
	Address:		35 positions		35 positions
		Private Mailbox		7 positions		7 positions
		City		21 positions		21 positions
		State		3* positions		2 positions
		Zip		XXXXX-XXXX* 10 positions		XXXXXXXXX 9 positions
	Taxpayer SSN Taxpayer EIN		XXX-XX-XXXX 11 positions XX-XXXXXXX 10 positions		XXXXXXXXX 9 positions XXXXXXXXX 9 positions
	Spouse SSN		XXX-XX-XXXX 11 positions		XXXXXXXXX 9 positions
	Taxpayer Occupation		20 positions		20 positions
	Spouse Occupation		20 positions		20 positions
	County		25 positions		25 positions
	School District		25 positions		25 positions
	Telephone Number		XXX-XXX-XXXX* 12 positions		XXXXXXXXXX 10 positions
Preparer Info	Firm Name		35 positions		35 positions
	Firm Address:		35 positions		35 positions
		City		21 positions		21 positions
		State		3* positions		2 positions
		Zip		XXXXX-XXXX* 10 positions		XXXXXXXXX 9 positions
	FEIN		XX-XXXXXXX* 10 positions		XXXXXXXXX 9 positions
	PTIN		9 positions	XXXXXXXXX	9 positions	XXXXXXXXX

* = may be preceded by a space

(Note: Depending on how the fields are generated by the different software companies, fields for Paper Filings, Electronic Filing, and 2-D barcodes may be interrelated. The field that actually appears on the printed form, in many cases controls how much data can be entered into an ELF or 2-D Barcode Field.

Example: If there were space constraints on the printed form which limited the County Name field to 15 Characters, this may affect 2-D and ELF lengths. If the ELF field and 2-D Barcode field were set at an allowable 25 characters, due to the Printed Form limitation of 15, only 15 characters would ever print in the ELF or 2-D Barcode fields.)

4.b. Field Standards for the 2-D Barcode
General Guide:

NOTE: Do not Zero-fill fields.

1. For blank fields, use a carriage return
2. Date -- MMDDYYYY, MMYYYY, YYYY, MMDD
3. "Yes/No" check boxes should be rendered as printed: if "Yes" box is checked, use an "X" for the sequence number assigned to the "Yes" box and a carriage return for the sequence number assigned to the "No" box. If no response (blank) use a carriage return.
4. Fields should never be Zero filled. To zero fill means to fill up the entire allowable length of the field with zeros. If the printed form requests that the field always contain some value or, if no value, then a single zero can be passed to the barcode.
5. Ratios and Percentages - these should match the data requirements that are established for printing on the form.
6. Filing Status Responses: If responses other than "X" or blank are desired in a check box area, the field(s) on the printed form should be set to accommodate a full range of alphanumeric responses rather than simply "X" or blank, and the 2-D barcode would return the same response as on the printed form. An example might be an area such as Filing Status where the agency wants to receive "1", "2", or "3" as the response, in a single field, rather than utilizing "yes/no" check boxes for each filing status. In this case, the form would be laid out such that there was one response box for the entire Filing Status area and the instructions for the form would direct the taxpayer to enter the number of the corresponding Filing Status in that box. Accordingly, that response (1, 2, or 3) would then be passed to the 2-D barcode.
7. Treatment of Calculated Fields - inclusion of calculated fields is up to the agency - data volume for "fit" within the barcode is the only issue.

4.c. Field Standards for Printed Forms
In the absence of printed instructions, round to the nearest dollar using the following rounding examples (for payroll forms, use rounding only if required):

16.49 -> 16
16.50 -> 17
16.51 -> 17
-16.49 -> - 16
-16.50 -> - 16
-16.51 -> - 17

Please refer to the government's instructions on this matter for authoritative guidance.

1. Dollar amount field size is based on 10 characters per inch:
1. individual returns = 12 characters max. $ amt. 999,999,999.
2. business returns = 15 characters max. $ amt. 99,999,999,999.
3. payroll forms = 14 characters max. $ amt. 999,999,999.99
2. Data field delimiters programmed as:
1. social security numbers: "-" delimiter XXX-XX-XXXX
2. employer identification numbers: "-" XX-XXXXXXX
3. dates: "/" delimiter XX/XX/XX
4. negative values: "-" floating minus sign - XXX
5. telephone numbers: "-" delimiter XXX-XXX-XXXX
3. Data type description and minimum number of print positions required are: (Note: *characters may be preceded by a blank space.)
1. taxpayer's name : 35
2. spouse's name: 35
3. in care of: 35
4. address: [35]
   - city (if separate field): 21
   - state (if separate field): 3*
   - zip (if separate field): 11*
5. taxpayer's social security number: 11
6. taxpayer's employer identification number: 10
7. spouse's social security number: 11
8. taxpayer's occupation: 20
9. spouse's occupation: 20
10. county: 25
11. school district: 25
12. telephone number including area code: 13*

Preparer information section: (Note: *characters may be preceded by a blank space.)

1. Data type description and minimum number of print positions required are:
1. firm name: 35
2. firm address: [35]
   - city (if separate field): 21
   - state (if separate field): 3*
   - zip (if separate field): 11*
3. federal identification number: 10

5. Testing/Approval Procedures

NACTP has issued guidance on recommended testing and approval processes. See www.nactp.org for additional specifics. As a general guideline, current software testing and forms approval timeframes and quality assurance practices should be followed in the implementation of 2-D bar coding.

a. Testing Processes

1. The agency must supply substitute forms developers with the test data to be used for the 2-D barcode:
- It is recommended that E-file customers serve as the test client base for 2-D applications.
- Agencies test scenarios must be provided on a copy of the agency's form.
- Test scenarios must be accurate and complete.
- Testing scenarios should include all fields required for full testing of the 2-D barcode. This should include agencies required fields such as SSN, FEIN and county/school codes.
- Agencies may base their test cases off the PATS testing scenarios. If the current year's PATS test cases haven't been released, agencies can use the prior year's test cases.
- Testing scenarios should be made available upon release of the 2-D specifications to expedite the testing procedure.

In addition, agencies can offer software vendors the opportunity to create their own test scenarios based on the agency's criteria. This allows software developers to forward forms earlier for approval when the test scenarios have been delayed.

2. Number of test scenarios
Up to six (6) sets of forms can be submitted for approval, to include:
- One set of blank forms
- A maximum of five test scenarios per form with either the same or different test scenarios. If a software developer includes the same barcode in multiple products (retail vs. CPA software packages, for instance), at least one of the test scenarios should be printed from each of those products with an indication of the package to which it belongs.
- If an agency requires a full field test scenario, this test sample must be part of the five scenarios allowed.
b. Approval Procedures

The agency should provide up-to-date contact information to software developers regarding forms acquisition and approval, including accurate email addresses and web site information.

1. Agencies should update their primary contact information in the interactive members only section of the NACTP web site. Contact the [email protected] for instructions to update this information.
2. Agencies must provide accurate backup contact information in case the primary contact is unavailable.
3. To facilitate forms approval, NACTP's preferred method of providing test scenarios for 2-D barcode testing is via PDF. Whenever possible, agencies are encouraged to support and allow PDF submissions by those software developers that are able to do so.
4. Form content/format, form scannability (when appropriate), and the 2-D barcode data string should be approved separately and simultaneously, if possible, to facilitate vendor internal processing and expedite the approval process. Agency responses to approval submissions should always indicate exactly what is being approved (content/format, scannability, and/or 2-D barcode data string) in such a way that software developers understand which pieces of the process are complete and which still remain unfinished.
5. Software developers should provide a cover sheet/letter attached to the forms with a list of the forms submitted and an area for an approval signature.
6. Agencies should notify software developers of the outcome of their review within 10 business days of receipt of the substitute forms.
7. Resubmissions: Software vendors should be notified within three (3) business days of receipt of substitute forms resubmitted.
8. Forms deemed "approved with corrections" should not require resubmission.
9. If the agency agrees, early testing can be done by submitting forms for a "preliminary approval". The 2-D barcode approval will not be given until the agency has ensured that all legislative changes have been included in the testing of the 2-D barcode.

6. Barcode Specifications and Version Control Process

1. Any document a state agency issues to developers should be numbered in sequence, dated, and should include revision marks to indicate changes. It is highly recommended that the state agency includes a “Change” column in their 2D barcode specification indicating that there has been a modification to a particular field. This column will have “New” for a new field, “Chg” for a changed field, and “Del” for a field that has been deleted or removed. If a state agency prefers, a complete list of all deleted fields may also be used in place of listing the deleted fields individually within the 2D barcode layout section. The deleted fields list should appear at the beginning or end of the 2D barcode specification, and may also appear in the “Highlights” or “What’s New” section.
2. The preferred document file format is portable document format (pdf).
3. Remove password protection from form files, especially if they are in a protected area designed for posting preliminary forms or other documents.
4. Updates and new forms and specifications postings should be announced through broadcast e-mail notification to software developers, including to the NACTP at [email protected].

7. Conclusion

Agencies, software developers, symbology vendors, tax administration systems integrators, and others are asked to support 2-D standards in their implementation of this technology.

Regular, ongoing standards discussions and opportunities for input will be afforded to agencies and market participants by FTA and NACTP. Continue to access www.taxadmin.org or www.nactp.org for updated information.

APPENDIX 1

Vendor Codes

Updated – October, 2009

If you are a vendor of 2-D capabilities and you do not see your company here, please contact Todd Goldberg, NACTP President, at 847-236-8369 or [email protected].

CLICK HERE for a list of Vendor Codes (pdf file – by Vendor Name)

CLICK HERE for a list of Vendor Codes (pdf file – by Vendor ID Number)