TaxDocuments: A Study of Product Acceptance in the Market

Edgar Yépez
Data Science

Abstract

This article presents a survey-based study conducted to assess the acceptance of a code library product, called TaxDocuments, for issuing electronic tax documents in the Ecuadorian market.

It provides an overview of the overall data management cycle applied to the study, covering data gathering, storage, cleaning, processing, and presentation. To enable meaningful interpretation of the collected data, the article briefly introduces the domain knowledge surrounding the product and supporting the study. However, for details on the general process of issuing electronic tax documents, as well as on the product itself, refer to the following article: [link]

As a conclusion, the article highlights the existence of two profiles that show interest in the product and are considered potential customers. The variables analysed throughout the study support further development of a highly targeted marketing plan.

This article is based on the Master's thesis Elaboración del Plan de Marketing de Posicionamiento en el Mercado Ecuatoriano para el Emprendimiento Tecnológico DocuEC available in the repository of the Pontificia Universidad Católica del Ecuador, and is the first in a two-part series summarising that work. The second part outlines a strategic marketing plan derived from the results presented in this article.

Introduction

TaxDocuments is a commercial code library developed to simplify the issuance of electronic tax documents in compliance with the standards defined by the Ecuadorian tax authority (IRS). The library is implemented as an embeddable software component that provides functionality to applications or systems requiring integration of automated tax document processing into their workflows.

Given the nature of the product, its target demographic consists of individuals working as software engineers, software product owners, or other software-related fields. In this regard, and with the aim of establishing an effective strategy for approaching potential customers, a survey-based study was conducted. The parameters, methodology, processing, and conclusions of the study are detailed below. Throughout the study, the product is referred to as an electronic invoicing library.

Parameters

The target demographic for the survey included individuals from a wide range of technology-related fields, despite the intended audience of the product itself. As such, a mix of professionals, lecturers, and students in technology-related disciplines were surveyed. The table below presents the parameters used to determine the sample size.

Variable Description Value
N Population size: Individuals with expertise in technology-related fields. ∞
Z Confidence level 1.96 = 95%
p Proportion in favour 0.5
q Proportion against 0.5
e Margin of error 0.05 = 5%

The approximate sample size, according to the formula n = (Z / 2e)² for an unknown or infinite population size N, is 385 individuals with expertise in technology-related fields.

Methodology

To enable accurate profiling, the survey focused on three areas: demographics, professional experience, and product acceptance. The measurable variables chosen across these areas make it possible to outline a profile likely associated with interest in acquiring the product. To this end, the variables were defined on the basis of a typical professional curriculum in the software development industry. The following presents the variables as a question bank along side their metadata.

Demographics

# Question Type Allowed Values
1 Age number Positive integers (years)
2 Gender single choice Female, Male
3 Province of residence single choice Azuay, Bolívar, Cañar, Carchi, Chimborazo, Cotopaxi, El Oro, Esmeraldas, Galápagos, Guayas, Imbabura, Loja, Los Ríos, Manabí, Morona Santiago, Napo, Orellana, Pastaza, Pichincha, Santa Elena, Santo Domingo de los Tsáchilas, Sucumbíos, Tungurahua, Zamora Chinchipe

Professional Experience

General aspects

# Question Type Allowed Values
4 Years of experience in software development number Positive integers (years)
5 Current affiliation single choice Independent developer or freelancer, Developer at a software development company, Developer at a non-software company, Professional in another tech field, Professional in another industry

Programming proficiency

Assessment of proficiency in a number of programming languages using the following scale:

  • Level 0: I have never used the language and need to study or review it first.
  • Level 1: I understand and use basic structures for both control flow and data handling.
  • Level 2: I apply development paradigms such as procedural programming, object-oriented programming, and functional programming.
  • Level 3: I am familiar with different software architectures and implement them using appropriate design patterns.
  • Level 4: I make use of reflection and metaprogramming.
  • Level 5: I actively contribute to the development of the compiler or interpreter of the language.
# Question Type Allowed Values
6.1 How would you rate your proficiency in C++? single choice 0, 1, 2, 3, 4, 5
6.2 How would you rate your proficiency in C#? single choice 0, 1, 2, 3, 4, 5
6.3 How would you rate your proficiency in Go? single choice 0, 1, 2, 3, 4, 5
6.4 How would you rate your proficiency in Java? single choice 0, 1, 2, 3, 4, 5
6.5 How would you rate your proficiency in JavaScript? single choice 0, 1, 2, 3, 4, 5
6.6 How would you rate your proficiency in PHP? single choice 0, 1, 2, 3, 4, 5
6.7 How would you rate your proficiency in Python? single choice 0, 1, 2, 3, 4, 5

Development technology preferences

Assessment of preferred development technologies in contexts excluding artificial intelligence, blockchain, and videogames.

# Question Type Allowed Values
7.1 What technology would you use for frontend web development? single choice I need to study or take a course, Angular, Blazor, Elm, jQuery, React, Svelte, Vue, Other
7.2 What technology would you use for backend web development? single choice I need to study or take a course, C#, Go, Java, JavaScript or supersets, Perl, PHP, Python, Ruby, Other
7.3 What technology would you use for mobile development? single choice I need to study or take a course, Apache Cordova, Flutter, Ionic, Java o Kotlin for Android Swift for iOS, jQuery Mobile, MAUI, Native Scripts, React Native, Swiftic, Xamarin, Other
7.4 What technology would you use for desktop or server development? single choice I need to study or take a course, C++, C#, Go, Haskell, Java, JavaScript or supersets, Julia, Kotlin, Lisp, Perl, Python, R, Ruby, Swift, VisualBasic, Other

Assessment of preferred development technologies in artificial intelligence contexts.

# Question Type Allowed Values
8 What technology would you use specifically for artificial intelligence projects? single choice I need to study or take a course, C++, C#, Go, Haskell, Java, JavaScript or supersets, Julia, Lisp, Matlab, Perl, Python, R, Other

Product Acceptance

General aspects

# Question Type Allowed Values
9 Which of the following stages do you consider is the most difficult to implement in an electronic invoicing solution? single choice - Generating the tax document in XML format according to its type and regulatory schema
- Electronically signing the XML document according to the established standard
- Sending the XML document for authorisation by the IRS
- Generating a PDF from the XML document for user-friendly reading
10 In a new software project, how would you conceive an electronic invoicing component for the project? single choice - I search for free open-source code online and complement or modify it with my own as needed
- I look for a native library for the relevant platform and install or embed it in my application
- I search for and commission a third-party solution or service, such as an online external API that handles the entire process
- I reuse an electronic invoicing component I have developed previously
- I design and develop an appropriate electronic invoicing component entirely from scratch
11 In a new software project, would you consider the availability of an electronic invoicing library when choosing a development technology for the project? single choice - Yes, I choose a technology that maximises reuse of completed and tested components, and I consider electronic invoicing one of those components
- No, the availability of an electronic invoicing library is irrelevant
12 On average, in how many of your software projects have you encountered the requirement to implement electronic invoicing? single choice - I have not had that requirement
- In approximately 25% of projects
- In approximately 50% of projects
- In approximately 75% of projects
- In all projects

Search channels

# Question Type Allowed Values
13 If you were to acquire an electronic invoicing library, which search channels would you use? multiple choice - General internet search
- Online repositories such as GitHub, GitLab, etc.
- Package managers such as npm, nuget, pip, cpan, etc.
- Social media
- Websites of trusted or known providers

Willingness to pay

# Question Type Allowed Values
14.1 How much would you be willing to pay for unlimited tax document generation for a single taxpayer for one year (values in USD)? single choice Up to $50, Up to $100, Up to $200, Up to $300, More than $300
14.2 How much would you be willing to pay for the same with no time limit (values in USD)? single choice Up to $200, Up to $300, Up to $400, Up to $500, More than $500
14.3 How much would you be willing to pay for unlimited tax document generation for any taxpayer for one year (values in USD)? single choice Up to $400, Up to $600, Up to $800, Up to $1000, More than $1000
14.4 How much would you be willing to pay for the same with no time limit (values in USD)? single choice Up to $800, Up to $1200, Up to $1400, Up to $1600, More than $1600

Purchase behaviour

# Question Type Allowed Values
15 If you were to acquire an electronic invoicing library at this moment, what would your role be? single choice - I search for an option and make the purchase myself
- I search and suggest an option, but someone else makes the purchase
- I wait for someone else’s suggestion and make the purchase myself

Product expectations

# Question Type Allowed Values
16 What three characteristics would you primarily expect from an electronic invoicing library? three-choice - Runtime stability
- Support for all features I need (e.g. just invoicing is enough)
- Support for all IRS-required features (even if I don’t use them)
- Comfortable programming experience or easy-to-read/write/remember code
- Clear documentation
- Code and documentation in Spanish
- Code and documentation in English
- Technical support
- Regular updates

Trust indicators

# Question Type Allowed Values
17 Which three trust indicators would most influence your decision to choose an electronic invoicing library? three-choice - Free evaluation option to assess quality
- Previous success testimonials
- Descriptive website
- Pricing within my expectations
- Performance statistics in production environments
- Performance statistics compared to market alternatives

Distrust indicators

# Question Type Allowed Values
18 Which three factors would lead you to reject an electronic invoicing library? three-choice - Runtime instability
- Outdated or obsolete documentation
- Code and documentation in English
- Late updates
- Source code not available
- No technical support
- No discussion forums
- Price exceeds expectations
- Price exceeds market alternatives
- Price below market alternatives

Processing

Responses to the survey were stored as a plain-text JSON documents, which allowed seamless integration into the data-processing pipeline.

Data pipeline

The data pipeline consisted of a preprocessing phase and an exploratory analysis phase.

Preprocessing phase

Preprocessing focused exclusively on questions involving categorical variables. Specifically, regardless of whether a question allowed single or multiple choices, each possible value was converted into a separate boolean variable indicating whether that option was selected or not. As a result, the processed dataset consisted of 172 variables across all types of questions.

Exploratory analysis phase

A statistical process involving principal component analysis was employed to identify the dispersion of survey responses within a manageable two-dimensional space. These dimensions correspond to the first two principal components of the original space, which account for the highest variance. As such, they do not necessarily represent actual variables for analysis, but rather enable visual interpretation.

Furthermore, automatic clustering based on the K-Means algorithm was employed to identify groups in which responses were similar to one another. Thereafter, for each group, the most frequently occurring value in each variable (the mode) was used to construct a stereotypical instance—understood here as a colloquial average—representative of that group.

Results

The survey was completed by 408 individuals from various professional backgrounds, though most belonging to technology-related fields. The exploratory analysis revealed three distinct groups in which survey responses shared common patterns. The following scatter plot shows responses as dots coloured according to the group, and their distribution in the two-dimensional space derived from the principal component analysis.

The following bar chart shows the total proportion of survey responses in each group.

38.0%
19.6%
42.4%
Group 1
Group 2
Group 3

Next, the aggregated results for individual questions are presented as bar charts specifying the proportion of responses in each group.

Demographics

General aspects
Age
From 20 to 25 years old (17.9%)
15.4%
From 25 to 30 years old (51.0%)
17.2%
11.5%
22.3%
From 30 to 35 years old (26.2%)
22.5%
From 35 to 40 years old (3.4%)
Other (1.5%)
Gender
Male (90.2%)
40.9%
14.5%
34.8%
Female (9.8%)
5.6%
Province of residence
Pichincha (91.4%)
40.0%
13.7%
37.7%
Imbabura (4.4%)
Other (4.2%)

Professional Experience

General aspects
Years of experience
Up to 3 years (33.8%)
7.1%
4.4%
22.3%
From 3 to 6 years (60.0%)
31.1%
11.5%
17.4%
From 6  to 10 years (5.9%)
4.2%
Other (0.2%)
Affiliation
Developer at a non-software company (53.7%)
38.0%
12.5%
3.2%
Independent developer or freelancer (26.7%)
23.5%
Developer at a software development company (18.4%)
3.2%
13.2%
Other (1.2%)
Programming proficiency
Proficiency in C++
Level 1 (11.3%)
8.8%
Level 2 (10.0%)
3.9%
5.9%
Level 3 (73.3%)
40.0%
30.6%
Level 4 (4.2%)
Other (1.2%)
Proficiency in C#
Level 1 (5.6%)
4.2%
Level 2 (12.0%)
4.2%
7.1%
Level 3 (77.0%)
39.7%
7.4%
29.9%
Level 4 (3.9%)
Other (1.5%)
Proficiency in Go
Level 0 (12.3%)
9.3%
Level 1 (25.0%)
16.9%
5.1%
Level 2 (23.0%)
6.6%
15.0%
Level 3 (37.0%)
17.6%
18.6%
Other (2.7%)
Proficiency in Java
Level 2 (7.6%)
4.9%
Level 3 (81.9%)
38.7%
11.3%
31.9%
Level 4 (7.1%)
3.2%
Other (3.4%)
Proficiency in JavaScript
Level 0 (5.1%)
4.7%
Level 1 (8.6%)
7.8%
Level 2 (7.4%)
4.9%
Level 3 (72.1%)
38.7%
31.9%
Level 4 (6.1%)
3.4%
Level 5 (0.7%)
Proficiency in PHP
Level 0 (13.7%)
9.8%
Level 1 (25.2%)
17.9%
4.2%
3.2%
Level 2 (21.8%)
4.4%
15.4%
Level 3 (37.3%)
18.6%
18.4%
Other (2.0%)
Proficiency in Python
Level 2 (12.7%)
6.4%
5.9%
Level 3 (68.6%)
31.9%
6.9%
29.9%
Level 4 (14.2%)
9.8%
3.4%
Other (4.4%)
Development technology preferences
Frontend web development
Angular (35.0%)
9.6%
13.0%
12.5%
React (27.9%)
20.8%
7.1%
I need to study or take a course (19.1%)
9.1%
9.8%
Vue (7.1%)
4.7%
jQuery (6.1%)
3.2%
Other (4.7%)
3.7%
Backend web development
Python (36.3%)
30.6%
4.9%
JavaScript or supersets (22.8%)
6.9%
15.7%
C# (19.9%)
3.7%
5.6%
10.5%
Java (16.2%)
9.8%
5.9%
Other (4.9%)
3.4%
Mobile development
jQuery Mobile (44.1%)
30.1%
4.4%
9.6%
Java o Kotlin for Android Swift for iOS (43.1%)
8.3%
12.3%
22.5%
Other (12.7%)
4.2%
8.3%
Desktop or server development
Python (52.9%)
36.0%
15.7%
Java (18.4%)
9.3%
7.8%
C++ (10.5%)
8.1%
C# (8.1%)
5.6%
JavaScript or supersets (7.4%)
4.9%
Other (2.7%)
Artificial intelligence development
I need to study or take a course (60.8%)
26.0%
9.1%
25.7%
Python (28.7%)
11.5%
7.6%
9.6%
Perl (6.1%)
3.9%
Other (4.4%)

Product Acceptance

General aspects
Most difficult stage of electronic invoicing to implement
Electronically signing the XML document according to the established standard. (96.6%)
41.9%
16.7%
38.0%
Other (3.4%)
Electronic invoicing component for a project
I search for and commission a third-party solution or service, such as an online external API that handles the entire process (69.1%)
40.9%
14.2%
14.0%
I search for free open-source code online and complement or modify it with my own as needed (22.3%)
19.1%
I look for a native library for the relevant platform and install or embed it in my application (7.8%)
6.9%
Other (0.7%)
Consideration of an electronic invoicing library
Yes, I choose a technology that maximises reuse of completed and tested components, and I consider electronic invoicing one of those components (79.2%)
42.6%
35.5%
No, the availability of an electronic invoicing library is irrelevant (20.8%)
15.9%
4.9%
Projects requiring electronic invoicing implementation
I have not had that requirement (25.7%)
23.3%
In approximately 25% of projects (64.5%)
33.1%
15.0%
16.4%
In approximately 50% of projects (9.6%)
8.8%
In approximately 75% of projects (0.2%)
Search channles
Internet search
Yes (97.1%)
41.7%
16.2%
39.2%
No (2.9%)
Repositories
Yes (68.6%)
30.4%
7.1%
31.1%
No (31.4%)
12.3%
9.8%
9.3%
Package managers
Yes (43.1%)
25.7%
15.4%
No (56.9%)
16.9%
15.0%
25.0%
Social media
Yes (66.9%)
28.4%
3.9%
34.6%
No (33.1%)
14.2%
13.0%
5.9%
Trusted vendors
Yes (59.1%)
38.0%
15.4%
5.6%
No (40.9%)
4.7%
34.8%
Willingness to pay
Price for a single taxpayer for one year
Up to $50 (89.2%)
34.6%
16.7%
38.0%
Up to $100 (9.3%)
7.4%
Up to $200 (1.5%)
Price for a single taxpayer with no time limit
Up to $200 (60.3%)
7.6%
16.2%
36.5%
Up to $300 (36.8%)
33.8%
Other (2.9%)
Price for any taxpayer for one year
Up to $400 (88.7%)
34.6%
16.4%
37.7%
Up to $600 (9.1%)
7.4%
Other (2.2%)
Price for any taxpayer with no time limit
Up to $800 (56.9%)
7.1%
16.4%
33.3%
Up to $1200 (39.0%)
34.6%
4.4%
Up to $1400 (3.2%)
Other (1.0%)
Purchase behaviour
Who executes the purchase
I search and suggest an option, but someone else makes the purchase (41.2%)
31.6%
5.6%
3.9%
I search for an option and make the purchase myself (39.0%)
36.3%
I wait for someone else's suggestion and make the purchase myself (19.9%)
10.0%
9.6%
Product expectations
Stability
Yes (19.4%)
8.3%
10.3%
No (80.6%)
34.3%
16.2%
30.1%
Supports all my requirements
Yes (22.8%)
14.2%
6.4%
No (77.2%)
40.4%
34.1%
Supports all IRS requirements
Yes (51.2%)
32.6%
16.4%
No (48.8%)
10.0%
14.7%
24.0%
Code easy to understand
Yes (39.2%)
13.0%
25.2%
No (60.8%)
29.7%
15.9%
15.2%
Clear documentation
Yes (51.0%)
23.5%
5.9%
21.6%
No (49.0%)
19.1%
11.0%
18.9%
Code in Spanish
Yes (1.7%)
No (98.3%)
42.6%
16.2%
39.5%
Code in English
Yes (1.0%)
No (99.0%)
42.4%
16.9%
39.7%
Technical support
Yes (31.6%)
7.1%
14.5%
10.0%
No (68.4%)
35.5%
30.4%
Regular updates
Yes (82.1%)
40.9%
11.5%
29.7%
No (17.9%)
5.4%
10.8%
Trust indicators
Free evaluation option to assess quality
Yes (90.9%)
41.9%
13.5%
35.5%
No (9.1%)
3.4%
4.9%
Previous success testimonials
Yes (60.0%)
23.3%
15.9%
20.8%
No (40.0%)
19.4%
19.6%
Descriptive website
Yes (40.4%)
21.6%
5.6%
13.2%
No (59.6%)
21.1%
11.3%
27.2%
Pricing within my expectations
Yes (37.7%)
34.1%
No (62.3%)
41.9%
14.0%
6.4%
Performance statistics in production environments
Yes (66.9%)
39.5%
12.7%
14.7%
No (33.1%)
3.2%
4.2%
25.7%
Performance statistics compared to market alternatives
Yes (3.9%)
No (96.1%)
41.7%
16.9%
37.5%
Distrust indicators
Runtime instability
Yes (17.4%)
6.9%
9.8%
No (82.6%)
35.8%
16.2%
30.6%
Outdated or obsolete documentation
Yes (86.0%)
38.5%
15.7%
31.9%
No (14.0%)
4.2%
8.6%
Code and documentation in English
Yes (2.5%)
No (97.5%)
42.4%
16.4%
38.7%
Late updates
Yes (81.1%)
40.2%
16.4%
24.5%
No (18.9%)
15.9%
Source code not available
Yes (2.7%)
No (97.3%)
42.4%
16.2%
38.7%
No technical support
Yes (13.5%)
8.6%
4.2%
No (86.5%)
41.9%
8.3%
36.3%
No discussion forums
Yes (13.7%)
12.5%
No (86.3%)
41.4%
16.9%
27.9%
Price exceeds expectations
Yes (33.8%)
32.1%
No (66.2%)
42.4%
15.4%
8.3%
Price exceeds market alternatives
Yes (49.0%)
39.7%
6.6%
No (51.0%)
10.3%
37.7%
Price below market alternatives
Yes (0.2%)
No (99.8%)
42.6%
16.9%
40.2%

Discussion

For each group, the mode of each variable was used to construct a stereotypical profile. The profiles are broadly summarised by their level of professional experience and their acceptance of the product. The first profile consists of adult professionals with three to six years of experience who would accept the product. Similarly, the second profile comprises young professionals with the same level of experience, but who would not accept the product. Finally, the third profile includes young professionals with no experience who would accept the product.

The table below presents the specific characteristics of each profile. Where applicable, the order of the options indicates preference.

Category Profile 1: Experienced Adult Professional Profile 2: Experienced Young Professional Profile 3: Inexperienced Young Professional
Demographics
Age From 30 to 35 years old From 25 to 30 years old From 25 to 30 years old
Gender Male Male Male
Province of residence Pichincha Pichincha Pichincha
Professional Experience
Years of experience From 3 to 6 years From 3 to 6 years Up to 3 years
Affiliation Developer at a non-software company Developer at a non-software company Independent developer or freelancer
Proficiency in C++ Level 3 Level 1 Level 3
Proficiency in C# Level 3 Level 3 Level 3
Proficiency in Go Level 3 Level 0 Level 3
Proficiency in Java Level 3 Level 3 Level 3
Proficiency in JavaScript Level 3 Level 1 Level 3
Proficiency in PHP Level 3 Level 0 Level 3
Proficiency in Python Level 3 Level 3 Level 3
Frontend web development preference React Angular Angular
Backend web development preference Python Java JavaScript or supersets
Mobile development preference jQuery Mobile Java or Kotlin for Android, Swift for iOS Java or Kotlin for Android, Swift for iOS
Desktop or server development preference Python Java Python
Artificial Intelligence development preference Need to study or take a course Need to study or take a course Need to study or take a course
Product Acceptance
Most difficult stage of electronic invoicing to implement Electronically signing the XML document according to the established standard Same Same
Electronic invoicing component for a project I search for and commission a third-party solution or service, such as an online external API that handles the entire process Same I search for free open-source code online and complement or modify it with my own as needed
Consideration of an electronic invoicing library Yes No Yes
Projects requiring electronic invoicing implementation In approximately 25% of projects In approximately 25% of projects I have not had that requirement
Search channles 1. Internet
2. Vendors/Peers
3. Repositories		 1. Internet
2. Vendors/Peers
3. Package Managers		 1. Internet
2. Social Media
3. Vendors/Peers
Price for a single taxpayer for one year Up to $50 Up to $50 Up to $50
Price for a single taxpayer with no time limit Up to $300 Up to $200 Up to $200
Price for any taxpayer for one year Up to $400 Up to $400 Up to $400
Price for any taxpayer with no time limit Up to $1,200 Up to $800 Up to $800
Who executes the purchase I search and suggest an option, but someone else makes the purchase I wait for someone else's suggestion and make the purchase myself I search for an option and make the purchase myself
Product expectations 1. Regular updates
2. Technical support
3. Supports all IRS requirements		 1. Technical support
2. Supports all my requirements
3. Regular updates		 1. Regular updates
2. Code easy to understand
3. Clear documentation
Trust indicators 1. Free evaluation option to assess quality
2. Performance statistics in production environments
3. Previous success testimonials		 1. Previous success testimonials
2. Performance statistics in production environments
3. Free evaluation option to assess quality		 1. Free evaluation option to assess quality
2. Pricing within my expectations
3. Previous success testimonials
Distrust indicators 1. Late updates
2. Price exceeds market alternatives
3. Outdated or obsolete documentation		 1. Late updates
2. Outdated or obsolete documentation
3. No technical support		 1. Outdated or obsolete documentation
2. Price exceeds expectations
3. Late updates

Conclusion

The study has revealed three distinct profiles, two of which showed interest in the product and are considered potential customers. Together, individuals within these profiles account for 82.2% of the total participants. Despite the wide range of professional backgrounds among them, the finding suggests broad acceptance of the product.

Alongside all the variables analysed across demographics, professional experience, and product acceptance, the study paves the way for the development of a highly targeted marketing plan focused on promoting the product and engaging potential customers.