Inspiration

What inspired us to go forward with this initiative was the realisation that double entry accounting is no longer enough for big corporations and conglomerates around the world, when it comes to their accounting systems. With the rise of new technology, comes the importance of security, efficiency and interoperability. Focusing on triple entry accounting and using blockchain technologies, we strive to help businesses improve their auditing systems with a transparent and avant-garde software solution.

With a core background in technology and a combined experience of 10 years between our team, we merged our interests in the emergence of new technology and the field of finance. We developed a scalable proprietary software that could improve the accounting and auditing systems of corporations in a seamless and easy manner.

What it does

TacTic is a non-intrusive software, which once purchased and integrated, runs under the hood to certify accounting records on the blockchain.

How it works

We wanted to have a seamless user experience where nothing would change for the accounting teams of our clients. We built a third party application that integrates with leading accounting softwares (quickbooks for now). Once installed, the app works on the backend (under the hood) and writes the accounting data to the blockchain. To fit with our branding, we say that the software is used to TAC (📌) or certify the accounting entries.

https://i.imgur.com/IPYUQlB.jpg

1) A client interested in using our software installs our app from the app store of their specific accounting system. This is the only required configuration. 2) An accountant issues an invoice for a purchase that was just made 3) Our api detects the invoice by listening on webhooks when available, or by doing a cron polling 4) Our backend generates data related to the invoice according to the openTac protocol 5) Once generated we attach a “TacTicID” to the invoice. This id uniquely represents this invoice and would be passed on to the receiver of the invoice. 6) The accountant sends the invoice by email to their customer as pdf 7) The customer receives the invoice, accepts it and adds it to their accounting system as a bill. The invoice pdf generated is attached to the bill 8) Again, through webhooks or polling, our api detects the creation of the bill, fetches the bill data and parses the pdf to extract the unique “TacTicID” At this stage, we create a bitcoin transaction with the following OP_RETURN data <OpenTAC prefix> <version> <invoice/receipt> <signature A> <public key A> <signature B> <public key B>

https://i.imgur.com/YjIzgQ9.png

9) Broadcast transaction to the blockchain and retrieve merkle proof

How we built it

We designed our project with scalability in mind and implemented our apps using microservices architecture. Our services are:

  • App (main website and webhook listeners)
  • Postgres12 (main SQL database)
  • RabbitMQ (Message broker for queuing)
  • Redis (in-memory data structure store)
  • Celery Worker (responsible for processing transactions and offloading to the chain)

For our tech, we used python and django to develop an api that would detect any changes in the invoicing of our customer's data and generate the data described above. Our backend uses postgres12 as a database and leverages Redis for caching and query optimization. It’s hosted behind a Nginx web server. Our api has a webhook listener that would detect any change on the accounting system of our clients.

An operation detected by the webhooks is offloaded to RabbitMQ, a message-broker server, using the AMQP( Advanced Message Queuing Protocol). We also built workers to read from these queues and process the operations (crearte, update, delete) on every object instance (invoice, bill, expense). This gives us async processing capabilities and allows us to easily scale up the number of workers on demand based on traffic.

Our app is dockerized and hosted on a kubernetes which would easily allow us to scale up and down when needed.

Challenges we ran into

  • Integrating with quickbooks was challenging. They have a large system and not all features are available for testing on the sandbox accounts. For example, email forwarding of invoices is only active in the production environment of quickbooks.

  • Each accounting system has their own way of dealing with invoices and different database schema. Standardizing these schema into a generic abstract schema was a bit tricky

Accomplishments that we're proud of

Some key challenges we faced throughout the process of developing this software was integrating with some accounting systems, as they have complex architects. For phase 1, we were limited with what could be done due to incompatibilities between accounting softwares. We focused on linking this software on Quickbooks to begin with. Moreover, like any project in BETA stages, there are continuous Q&A tests that were done to ensure optimal effectiveness.

What we learned

Accomplishments we're proud of are creating a brand and building on top of that, as well as getting an end-to-end proof of concept running to confirm the validity of our idea. This helped us learn the obstacles involved in building such a product. This process was phase 1 of our software approach and release. For phase 2, we strive to deploy TacTic’s software on Bitcoin Main net and support other main SME accounting vendors such as Xero, Sage and SAP.

What's next for TacTic

Deploy Tactic’s software on Bitcoin Mainnet as well as support other main accounting vendors such as:

  • Xero
  • Sage
  • SAP ERP

Note

Within this submission, we've included a presentation of our Business Model and Digital Marketing Strategy. To access this presentation, you can click the following bitly link

We added the bitcoin association github account to our private repo

You can find our video here

Share this project:

Updates