Real-time invoice verification by tax authority

No. Manager has no native functionality for direct data exchange with other computer-based systems.

On a brief read

I haven’t read enough of your requirements to determine what is really required here

The complexity lies in then interface to the “fiscalization service”

XML should be achievable.

Please clarify, @Patch. I don’t believe you are referring to any built-in functionality, are you? Aren’t you looking towards what might be achievable using the API, possibly exploiting report transformations?

Report transformations: Yes

API: No. While it is true it would work for a single user, the subsequent solution could not be distributed to every other Manager business in Montenegro. Which makes the cost per Manager business prohibitively high.

To try to answer my own questions

The tax administration would like reporting to their Central information service (CIS) at the time each sales invoice, at least some purchase invoices, credit note, debit note, Invoice reverse charge, invoice correction (date/time or type or bad debt or deadline), (or cash deposit) is made.

However where a user is off line the data can be batch submitted at later time. They suggest via a USB pen drive. A QR code is printed on invoices which links to the CIS. Should a customer find the supplier has not uploaded the invoice in a timely fashion, the tax administration suggests the customer should report the supplier.

The implications of this are:

  • The later batch mode would be best implemented using Managers existing Report transformation interface.

  • Live reporting per invoice / debit note / credit note / correction could be implemented using Managers existing Report transformation interface. Perhaps by having a second Manager tab open on the report transformation and running it for each invoice / credit note / debit note / correction. However in a multiuser environment that would be sub optimal.

A better live reporting solution would require Manager program support. Perhaps a custom field type which calls a report transformation and returns a QR code. However the best solution for Manager would be to enable support of the range of requirements of the majority of the jurisdictions, not just Montenegro’s requirements.

All but summary data. Including

  • Payment method (Notes/coins, Credit/debit card, Bank cheque, onetime voucher, company card, summary invoice, Advance payment, transaction account, Factoring, Compensation, Transfer of rights or debts, Debit waiver, Kind paying)

  • Currency & exchange rate

  • Operator, issuer, buyer, and seller identification

  • Amount (total, VAT, without VAT, VAT rate), Margin, Fees, Rebate, unit price, quantity.

  • Date/time submitted to Tax authority, Date & time invoice created, Date & time invoice issued, Invoice deadline date, Date or range of dates supplies delivered.

So more information than Manager normal collects

One way TLS connection using HTTPS (SOAP 1.1) protocol to a web service at the Tax administrations Central information service (CIS).
All messages signed using a private key (issuer or CIS)
Real time error reporting is included

XML, format defined as well as version definition and updating requirements.

In summary, points 1 and 2 above imply a significant body of work to achieve compliance.

  • Sound about right to me.

  • May be able to do better with subsequent jurisdiction in Manager.

  • Maintenance of course becomes an issue with time.

All this is well beyond my expertise, but these requirements sound incredibly intrusive and realistically unachievable outside a dedicated, integrated (on both ends) system.

1 Like

I think users can share baseline API code to decrease the workload.
See some earlier API discussion in this forumpost:

I have once tested such XML extraction and I posted in the above forumpost which fields need attention in Manager for this to work smoother and that is besides getting the finalized API. So after ploughing through this conversion to XML I can only say that this process is loaded with technical and localized complications. A basically standard multiline invoice is between 200-300 lines of XML code. Therefore it is my opinion it doesnt matter how far Manager can go in setting up XML code, theme, template, custom report or report transformations for this purpose, I think there will always be need for local pruning in some other software. So why not just move all the “raw” data from Manager to this other software with finalized API where the XML code is structured 100%. Such pruning can be done for each government or tax authority’s liking in corresponding countries, states or whatever it may be. Maintainance of code, going forward, can also be done through the API as it has the flexibility and speed locally for XML coding purposes. So although not being a programmer, API is my bet :slight_smile:

It seems tax authorities and/or governments in many countries are going forward with such real-time or XML demands towards businesses. This will put pressure on accounting systems to comply.

I fear you are right, @Tor. Unfortunately, that will mean fewer options for accounting systems on the market. Only a few—or perhaps just one subsidized—developers in most countries will have the resources to develop and field such end-to-end systems. Practically none will pursue universal adaptability for all countries.

This discussion started with an inquiry from Montenegro. In a relatively small economy like that, it is possible to conceptualize such a scheme. Jump to a lager economy with not only national but provincial or state and even municipal layers of governance and taxation, and the idea quickly becomes unimaginable.

The application programming interface (API) in Manager is a low level web interface to Manager (a web program). Being low level, it can replicate most things a user could do manually, but via that interface it can be automated.

This is a very different concept to a standardized data interchange interface. The latter is static across many versions of software on either side of the interface, programs on both sides explicitly convert their internal representation to and from the interface standard.

Personally I would be very surprised if Manager ever provided such a fixed data interchange interface. In my opinion it is far more likely the details of Managers API changes as the underlying program evolves. This assertion is based on what the API is actually offering and the percentage of managers paying customer base depending on it.

The same issue currently also applied to the Report transformation mechanism. The difference is the entire process is visible to all people working on customizations for Manager (including Lubos). And also the percentage of the paying user base relying on it.

I agree choosing a local data integrator with the simplest interface is sensible. I disagree it is optimal for Manager users to to run another program on their computer. The issue is the difficulty in doing so in a manner the majority of Manager uses could reliably achieve.

The new report transformation interface is far more powerful than the old. Most data is now exposed. You are correct it does not currently have the ability to write back to Manager. Not an issue if the user is copying an authorization code from their tax authority back into a Manager custom field, but is a problem if the process is legislated to be completely automatic.

As for programing efficiency across jurisdictions, that is best addressed by making solutions for each jurisdiction public (as report transformations currently are). That way when writing an interface for a new jurisdiction, a programmer can start with a solution for another jurisdiction with similar requirements.

Guys, thanks for your input. Seems like API is the only solution to these issues, if I am understanding right.

Does anyone have any idea when API will be available? If it’s not ready soon, I have to move to another accounting software…

It has been available and worked for several years.

If you want time scales on when something different will be available, then you will need to make your own guess. I’m not aware of a substantial change to the API plan / idea.

Improvements to the report transformations have been discussed recently.

@cavlovic, I took a look at section 3.7 and this seems to be about XML invoices and I think you will always need to talk to some local IT company which provides service and connection to such central hub for XML invoices. Atleast start by consulting local IT company which can give you specific answers based on your business needs.

Getting the data to make the XML files is not a solution provided out of the box in Manager atleast as of now.

I think there is some misunderstanding, I always ment that it the local data integrator will use this another software - so we are on the same page there :slight_smile:

1 Like

I was going to hire someone locally to make an “interface” to communicate with Manager, but I honestly don’t know where to start. I cannot find any API documentation online, just posts saying it is going to be available later.

Where should I point them to take a look and see if they can make this happen?

See what @ShaneAU recommends in approaching the Manager API in this forumpost:

He says “self-explanatory / almost serves as documentation by itself” which is what we have basicly as there is no documentation in the guides.

You can also search for “API” in the forum where there are many interesting forumposts. I think there are a few, most likely programmers, which have managed to harness the API but I don’t know their use case as such. Remember you can post API questions in the forum to get some answers.

If you take this forward, please do share your experience as there are others in the same steps.

I had been trying to access this API link but link wasn’t working. I just realized with their recent move to Linux servers, links have changed… With simple link edit, I can access it.

After a quick look, there is an easy way to connect to the API and do edits to businesses, but I don’t think this will do. I would have to make an app to constantly connect and look for changes, and if there is change, connect to TA, push the invoice, get QR code, apply it to the invoice. This is not going to be reliable solution, especially not for an accounting software, and it’s too clunky.

I will keep digging and try to see if there is another way to approach this.

Ok I understand, your business case has to work in real-time. But what if there is a small business which lets say only issues a couple of invoices in the end of each week ? Then a manual start of the connection to push all the invoices all at once could be acceptable for such a business ?

In order of preference, in your situation I would:

  1. Look at not using your accounting system for point of sale transactions. Cash registers which are compatible with your government’s requirements would be available.

  2. Use your government’s offline submission option. A report transformation could easily generate the outgoing data. Batch update could be used for the incoming data.

  3. Real time data interchange is hard. Lubos maybe interested in working with your programer as a test case however if I was him I would get a European example working first as the market is larger

This is only viable option for me. Montenegro did not make this system, nor the implementation. We have implemented it from some EU countries and I believe it’s going to be the EU standard. This system is still in testing phase in Montenegro in November, and I could provide with testing account and help the program be registered locally so it can be used in MNE.

If @lubos is interested, we could work on it and we could test it. Implementing in MNE doesn’t make time investment sense, I know, but only as testing grounds as other countries will, sooner or later, do the same.

We have similar law in Fiji. I wonder if there are any developers on this forum working towards such implementations.