Modernization Hub

Modernization and Improvement

Automating Tax using Google Cloud Platform, (it really can be done!) (Cloud Next ’19)

name is Brady Dever. I’m a partner in our PWC
practice in Australia. I’ve got a colleague
here who’s going to be co-presenting
with me today, Ed Knust, who’s a director in
our PWC Australia practice. We’re really excited today
to be given this opportunity to talk to you all and present
here at the Google Next conference about a solution
that was really spawned off of the same conference
nine months ago, where we, like you guys, were sitting– PWC, Ed and I in
particular were very lucky and fortunate to have an
invite to this same conference. And we were sitting
in the audience looking at a couple of
solutions platformed on GCP and using some of the
ML and OCR technologies that Google has for some
accounting problem solves. And we were sitting
there as tax guys thinking, gee, how
good would that be if we could take it
a slight step further and start to solve on top
of the accounting fix, some of the bugbears that we
see in our day-to-day lives as advisors and also
some of our clients from a tax calculation
and classification perspective in systems? And so, that was really
where we started. So we started as an
idea, as a thought bubble nine months ago in July. Literally, the next day,
we were lucky enough to have some of our Google
Partners catch up with us, and we were able to
then sit down and walk through some of the ideas. And we were really,
really fortunate that Google kind of bought
in really, really early into this opportunity. And so, a very, very short
but intense journey kind of started in July last year to
get us to where we are today. So really, really excited about
to show you where we’ve got to. So what we’re going to do today
is just spend a few moments, if OK, around the
business problem that this technology
is aiming to solve. Conscious, given that
we’re in the United States, the use case that we’re
talking about here is indirect tax, value
added taxes, and GST, which is largely a non-US tax. So I might just spend a little
bit of time, if OK with you all, just to walk through the
basics of what the business problem is and the tax
problem that this solution is trying to solve. I’ll then hand across
to my colleague Ed, and Ed will give us
a live demonstration of the solution in action. It has just come out of
POC phase in Australia. We’re really excited
about the initial results and super keen to show
you what it looks like. Then, we’ll talk a little bit
about development roadmap given that we are just out POC and
we have got big plans for this. So we’ll talk a little
bit about that– how we’re planning to adapt it
in certain jurisdictions given the differences in tax
and business problems across the world. And then, we’ll spend
a little bit of time on some of the future use
cases and some of the questions that our clients
have already started to ask us around what the
solution could potentially do outside of tax. And then, hopefully, if
we can stay to time– and I know Australians
are notorious for waffling and talking– if we can keep to
time, we’ll make sure we’ve got a few minutes
at the end for some Q&A. And when we do do
the Q&A, we ask that we’ll just have of you all
is if you could just stand up and maybe just take a microphone
in the aisle here to talk. OK. So the tool is called Zipline. There’s a story behind the name,
and some of my Google Australia colleagues in the front
seats here will know. I’ll give you the
official reason why we’re calling it Zipline. It is an OCR and IA
combined solution. The reason why we’ve
called it Zipline– it has got a meaning– is because we see this piece
of technology as solving or bridging a gap that has
existed and has been a bugbear in my world as an indirect tax
advisor and my clients’ worlds trying to cope with indirect
tax automation in systems, because it’s the last area where
there is a manual process that can’t– until now– have been automated. And we’re really excited
to be able to say that we can get these
automated on the accounts payable side of the tax ledger. And so, for that reason,
because we’re bridging this gap, we called it a Zipline. And then, the
simple reason why– the other reason,
so it’s got a double meaning– the other
reason why it’s a Zipline is because the PWC office and
the Google office in Sydney is literally separated
by 100 yards of water, and it takes us half an hour,
45 minutes to get across. But if we add a zip line,
we’d be there in two seconds. So that was part of
the other reason. And so, like I mentioned,
this is an OCR AI tool. Ed will talk a bit about
functionally and technically how it works. I should just caveat that by
saying, for all the techies in the room, we aren’t techies. We’re tax people. We know enough about the
tech to be dangerous. What we’ve been really
fortunate to have in both of our organizations,
in Google and in PWC, is a whole bunch of really,
really smart tech people and engineers that can
help us bring this to life to solve the business
problems that we have. But we will do
our best to answer any of the
technological questions around sort of functionally how
it’s set up to the extent there are any of those questions. OK. So the business issue. So VAT and GST– so Value Added Tax,
predominant tax on consumption in Europe
and in most of Latin America and in most of Asia-Pacific. It’s called Goods and
Services Tax, GST, in some of those jurisdictions. It’s a little like
sales tax in the US, except that it’s two-sided. So not only do businesses that
sell goods and services have to collect and pay tax to
the authorities on the things they sell– so that is a feature of
the GST and VAT regime. The critical difference between
GST and VAT and sales tax, however, is that– and this
is the two-sided nature of the tax– is that you as a
business are also charged VAT and GST on
the things that you buy. So it’s an input and
an output system. The good news for businesses
is that, for the vast majority of the purchases that businesses
make, the VAT or the GST can be reclaimed. It can be recovered as a
refund from the tax offices. But, this is subject to a
couple of key conditions, and this is where the
manual problems have existed in our world since the 1970s
when the tax was conceived by the French. The two key conditions
to be able to get that GST or VAT that’s been
incurred on your purchases back from the tax
authorities, one, that it is a specified
business-eligible purchase under local VAT and GST law. So there is a legal requirement
that you need to meet. And that’s based on tax
rules and legislation. That business and
tax legislation– those tax rules– are then
augmented or qualified by the type of
business that you are. So there’s a legal question,
is it or isn’t it recoverable? And then, the second question
is, based on the business type that I am as an acquirer
of services or goods, how does that impact or change
my recoverability of that tax? So that’s the technical problem. And in 150 countries
around the world, those rules are all different. The second problem is
a document problem, and we we’re lucky enough to
kind of hear some of the Q&A and the interviews over in
Moscone just before we went live. And one of the ladies was
talking about dark data, and that’s data that is
trapped on a paper document in an unstructured form. And that’s the problem that
we have in the VAT world on purchases. We need to be able to identify
that we hold a valid document to support our claim. So one, we need to make
sure we’re legal in terms of complying with the law. Two, we need to check that
against our business type. And three, regardless of
what goes into our system, we need to hold a valid
document in a specified form. And so, what that has meant
in terms of business process is that, typically, VAT
and GST on purchases has been systemized to a degree. And that is effectively once the
data is input into the system. So when a purchase is
made, a PO is struck, and an invoice is received– either a vendor invoice
or an employee expense, there’s a big piece here
around employee expenses– somebody has to actually lift
the data off those invoices, make a GST or VAT decision–
what kind of expense it is, is it recoverable,
and if it is recoverable what code do I then
apply to the transaction as I’m posting that
transaction into the system. Once the transaction
is in the system, systems are very, very
good at then automating how the GST should then
flow through the accounts and then ultimately
onto a return so that you can claim it
back from the regulators. So that’s what effectively
we mean by a tax engine up on the screen. So tax engines are
really, really good at running rules-based logic
to identify and capture GST or VAT, but
the key criteria is that we capture that data
off of those source invoices. And that old adage
of junk in and junk out is really, really
true from a VAT and GST perspective on purchases. So what we find, as
we’ve talked about, is a very manual process
across a number of our clients across the world. And that could be a native
accounts payable function that sits on-site. It can be a BPO, an
outsourced function, but there is always inevitably
some form of document checking, manual input, and process. And what we see is it creates a
lot of issues for our clients. The first issue
is it costs money. And I’ve got a stat up
there from firm SAP Concur they estimate across
the VAT world, GST world there’s around $20
billion US of VAT and GST on taxes, on hotels,
on flights, on meals that just goes missing. And the reason why
it goes missing is because, one, businesses see
these as low-cost purchases. But they do add up
over time, obviously, given the number on the screen. Two, the employees often that
are making reimbursement claims need to make those tax
decisions off of the invoices. And three, because of that, the
risk of an employee selecting a wrong tax code
is simply too high, so businesses choose not to
engage and claim that GST back. The second thing in
the vendor world– so outside of the
employee expense world, in the vendor purchases world– we see a lot of problems,
particularly in Australia, around that manual process
risk on accounts payable. And some of the stats out
of our Australian tax office actually show that almost
70% of errors on the accounts payable side– and this is data
collected across the whole of the Australian
taxpayer base– are caused by system
and process deficiency. So there’s risk. That can go both ways. You can overclaim or underclaim
because of the manual gap. And then, three, efficiency. So you’re asking in this manual
world accounts payable and BPOs who aren’t often tax trained to
make tax decisions and process documents for tax purposes. And that takes time
and effort that can be redeployed to other
more value-adding tasks in a business. The last thing
that I just wanted to touch on in terms
of the current state and why we saw this is a
really key problem to solve is that the VAT
and the GST world is undergoing a huge
shift at the moment, which is driven by technology. So as it stands, in the majority
of the VAT and GST world at the moment, it’s a
traditional tax compliance reporting system. And what I mean by that is
transactions occur in a period, in a month. The month stops. We’ve got 21 days
to then collate all of that data
out of our system, put it onto a tax
return, and file. And in that 21-day
period between month end and when we need
to file, there’s time for us to run checks,
to extract reports, to do reconciliations,
and to file returns. So we’ve got time to
look back over our data and check that it’s right. The problem is, where
we’re now moving, is to what I call a real-time
reporting electronic filing regime. And this is no more pronounced
than in places like Spain, where the regulator now
says we’re doing away with that VAT return traditional
process and we’re replacing it. And what we’re
replacing it with is, every four days, I want a
direct upload out of your source systems as a client, and I
want your AR, I want your IP, I want you GL, and I’ll work out
how much tax you have to pay. And I’ll do it every
four days, and you have to pay it every four days. So you can see that
fundamental shift from a time lag between
when a transaction occurs and when we need to report and
we need to collect and pay, to now that being
much more compressed and the tax offices
across the world having a lot more of your data
than previously you gave. So for us, what that
means is it really, really enhances this importance
of getting those tax decisions right in the system first time. And so, we think Zipline
does a lot of that. We think it fills that last
mile between invoice receipt from third-party
suppliers, from employees who want their expenses
back, into the system to allow tax rules and
classification to work to get your data
right in the system at the time the
transactions are processed. And I might just
hand over to Ed now just to give you
a little bit more overview in terms
of the solution and where we’re at both
as a standalone offering, but also some of the
exciting opportunities that we’re looking at
the moment in terms of partnerships and
integrations with ERP providers and expense platforms like SAP. So for example, we’re in
the middle of conversations right now with SAP Concur to
have integration capability to actually have this
as an ongoing subprocess within your employee
expenses system– similar also for the accounts
payable modules in the core ERP providers. So at the moment, a
standalone solution, but we’re really, really excited
about what integration looks like and having this ingrained
as a subprocess for tax inside of the ERP in the future. EDWARD KNUST:
Morning, everybody. We’ve got the solution
overview on the left-hand side. As Brady mentioned, I’m
not a tech guy either, but I can talk it
through basically what the technology stack is. I think the key points are
on the right-hand side. So what are we doing? We’re extracting the data
from the underlying source invoices utilizing
Google’s Cloud Vision API, and we’re also using a
machine learning base model to take that OCR output
and to classify the fields on the invoice or the receipt. As Brady mentioned
before, we then have to validate whether
what’s on that invoice meets local requirements. So there’s a set
of tax rules which we’ve built in from each local
jurisdiction as to what fields are and are not required. Part three is where it
starts getting really interesting because, having
then taken those data fields, having applied the ML logic
to get the relevant data fields categorized, we can
then run PWC classification over what that expense type is. So as Brady mentioned before,
different expense types are capable of
different tax credits. So the capability
we’ve built in here allows for an expense
type determination and differentiation
between that expense that’s been incurred where it’s
relevant for tax recovery. And lastly, we get a
validated tax reclaim amount per transaction line item. So if there hasn’t been a
booking in the underlying system, that will be the
GST reclaim amount or VAT. If there has been, then we can
reconcile the Zipline output with the underlying
system output. To the extent that
there is a difference, that can be investigated. So if we look at
the solution itself, I think the key
point is that we’ve got those two different models. So for invoice
extraction, we’ve got an ML model that sits over
the Cloud Vision API data extraction. We also use the Cloud
Translate capability where the invoice is not in English. And we have that separate
model for the classification in the bottom right-hand
corner of the expense type. So for those who are interested,
the model that we’re using is a long short-term memory
recurrent neural network. I think I got my memory right. BRADY DEVER: Sorry. Just to jump in before
we jump into the, demo I think that’s a really
important point in terms of those four gates, in
terms of the business case that we started to think about
nine months ago when we first saw some of this
technology in use. So there are a lot of OCR– as many of you in the room will
know– a lot of OCR providers that look at
expense posting data extraction from unstructured
into structured. The thing that we
really like about this– and particularly the
Google technology that sits behind it
in the Vision API and the deep learning models– is that, unlike a number
of other OCR providers, which takes a template or
grid-based approach to OCR where we teach the
machine to look for things in certain quadrants
of a document, the benefit of the
Google technology here is that, because of
the deep learning model that sits behind it and the hundreds
of thousands of documents that have set in the
training data set, is that the tool keeps
looking no matter where the data is
located on a document to get the thing that we need. So that’s the first
thing that I really like about the Google tech
and the differentiator that it gives. The second thing,
which is where I think the incremental value
comes off some of the existing OCR processes for tax, is that
not only does it just extract for the purposes of posting. It extracts. And while it’s extracting,
it apply smart logic to work out whether
the document is valid from a tax perspective–
to solve that point we spoke about before. And then, it also does
things like pings internet registers for tax authorities
to validate that the seller is who they say they are, that
their ABN or their VAT ID is correct– so they are
genuinely registered. And that matters in a
lot of jurisdictions. And it also validates the
GST calculations or the VAT calculation. So are we seeing a $10 GST
amount for $100 purchase. In Australia, the
VAT rate is 10%. So it is doing a whole bunch of
smart calcs using the ML, based on tax rules and logic that
PWC has co-created together with Google, to
actually lift the data and do smart things to
it on the invoice level. So that’s gate one. Then, once we get through
the invoice validity phase, we then kick it into
another ML model, which is a tax engine which
actually runs categorisation– so looking at, for example,
if we’ve acquired stools– how does the body of data
that sits in the ML model categorize stools
for VAT purposes? Office equipment. So it was a stools
equals office equipment. And that will then do
the order categorisation, which then allows
the standardization to occur for a tax
calculation rules set to then do the rest of
the job in the system. And so, the smart
technology that Google has in Vision API and
their deep learning models, the TensorFlow models
that sit behind the tax rules engine augmented and
supplemented PWC tax content for us is where the
magic happens in this. And we’re really,
really keen to show you how this works with a
few real-life scenarios. But, that I think is the key
differentiator between this POC and what other OCR providers on
the expense side in the market do today. We actually add some
smart analysis at the time that the OCR is
scanning the invoices and processing those invoices. Sorry. EDWARD KNUST: No, that’s fine. So if we can move on
to the next process, which outlines what the
business process actually is at the moment. If we have a look at
the top line here, this is what’s happening within
the expense management system. So we’ve got data
going into the system. We’ve got typically an AP
clerk or an employee making those classification decisions. Where Zipline comes in
is that second line. So as Brady mentioned,
the TensorFlow models, the Cloud Vision API, the
Translate API where required will kick in. And then, that triggers
the automated process of that validation
classification and then tax credit
calculation, which can then feed automatically
onto a tax return or in a live
reporting environment direct to the tax authority. So with that, I’ll
jump into the demo and show you exactly
how it works. Excellent. So you will notice that
the UI has not been designed as a client-facing UI. At this point in time,
this is an internal PWC UI. We are developing client UI. But for the purpose of
the proof of concept, we kept this as an internal one. But certainly,
our anchor clients are very interested
in the visualizations that we can take
from this process. So the first step is
going to be to get the documents into the system. So here, I’m going to
select five invoices. We’re going to upload those
invoices into the system. You can see that that
happened very quickly. We are unconstrained by volume. So to give you an example,
one of our anchor clients has several hundred
thousand invoices. Again, the power of the
Google tech allows for the OCR to happen in a matter
of milliseconds. So we’re completely
unconstrained by data upload. We are working with partners
such as SAP and SAP Concur on utilizing their APIs to
go direct into their systems because of bulk data extraction
that using their APIs is most efficient. That said, we also have
developed RPA solutions to allow for bulk
extraction of data where an API is not available. So those files have
now been uploaded. You can see that we
have each of them here. To the extent a file
has been multiple pages, it’s automatically split
it into individual pages. We can now go in and look
at a particular invoice. So here, we’ve got an
Australian invoice. It is a valid tax invoice. So we’ll show you how the
OCR process has worked. So the OCR has identified each
of the individual text blocks on the invoice. Once it goes through
the TensorFlow model and applies the machine
learning, you’ll see– it’s probably in
small text here– but you can see that it
has identified things like the vendor name, the
vendor tax registration number, the date of the
invoice, description, et cetera. On the right-hand side, we
have all the relevant fields for, in this case, an
Australian invoice. And again, given that we
have the content of the PWC global network, we
know what fields are required for
what document type in every location around the
world with a VAT or GST system. So you’ll see here that
that TensorFlow model has taken each field and identified
whether the value exists within that invoice. So here, we do have
the phrase tax invoice, which is a requirement. We’ve got the date, total
amount, GST amount included, the vendor’s tax registration
number, et cetera. So as I said before, in
a matter of milliseconds, we’ve taken an invoice, it’s
been uploaded, and then OCRed, the ML model applied, and we
now have all the relevant fields available for input into the
underlying system or validation of the underlying data import. So all of those invoices
have now been uploaded, and we’re then going to
visualize that through what we call the Swift Dashboard. So the Swift Dashboard is
where that stage two, ML, has happened. So this is where the expense
classification and validation is taking place. So you see here, we’ve
got some stats up top. We’ve got how many
transactions have been uploaded into the solution, the total
value of transactions that’s been classified,
the total VAT spend on those transactions, and then
the resulting VAT claimable. So going back to Brady’s
earlier point on live reporting, here we can take an entire data
set for a larger organization. And within a matter of minutes,
it’s gone through the process, been validated, and is
producing a VAT claimable amount which can go on
a return or directly to the tax authorities. We’ve got some visualization
here over the amount, the VAT spend, and the categorizations. And as I mentioned before,
we’re developing this further with clients for a
client-user interface. But what I want
to do now is just take you through what
those five invoices were and to show you how the
classification and validation process has worked. So I’m going to start with
one which is a valid invoice but is foreign. So a foreign
invoice is not going to be subject to
reclaim in Australia. If we have a look here, this
is an invoice from Singapore. It’s a hotel invoice. This would be a
valid invoice if it was being incurred by
a Singaporean company in Singapore. But here, it’s being
incurred by an Australian, so it’s not claimable within
the Australian GST system. So if we click back
into Swift, we’ll see here that it
was a valid invoice. However, it’s been
classified as foreign. It’s listed the total amount. It’s listed the VAT spent. And here, it’s made that
tax calculation decision that the tax claimable
is $0 on the basis that it’s not local tax. Interestingly enough, there
are a lot of cross-border tax credit mechanisms. So even though it’s not
claimable within Australia, we can then report for
potentially a Singapore reclaim where the client will
be able to claim that $73 back in a
separate tax return. We move on to the next
example, and this is the one that we really try and avoid. This is where we’ve
got a local invoice, but it’s not a valid invoice. If we have a look
at this example, This Is an Uber receipt. The value here is $83. In Australia, we have a rule
that anything above $82.50 requires certain requirements
that aren’t required under that threshold. So one of the requirements
is it must have its own tax invoice at the top. You can see here that
the term invoice appears, but the term tax
invoice does not appear. As such, when we look at how
the solution has prefilled these fields, it does not apply
to value for the tax invoice phrase appearing. On that basis, when we go
back into the solution, you can see that it’s
been deemed to be invalid. It’s domestic. There is an amount of
tax on the invoice, but it’s not claimable because
we have an invalid document. These are the types
of documents that are really useful from
a management reporting perspective to then inform
the control and process environment upstream about
what type of data and invoices is being provided by
either vendors or employees into the relevant systems. Because here,
we’ve paid tax out. We do have an implicit
right to claim it if we have a valid document,
but for whatever reason we don’t hold that document. If we did, we’d
get the tax back. This is a massive gap
in our client base where they’re paying
substantial amounts of tax out, but the document is not valid. The third example
is a valid one where there was no GST on
the underlying invoice. So if we have a look here, this
invoice formatting is perfect. it has all the required fields. But if we have a look, it
was international travel, and therefore there was
no GST in the price. So the solution
has classified that is a valid invoice,
as a domestic invoice, but with no GST recovery
because there was no GST spend in the first place. One of the risks with
previous solutions is that, when you have a
category like airfare– which could potentially contain
tax or not depending on whether it’s domestic versus
international travel– if you automatically assign
a tax credit calculation to that airfare
category, that may have imputed a tax credit,
in this case, where there was no tax paid. So by going into the source
document and validating it, we take out any risk that
the underlying classification of that expense type account
may have been incorrect. BRADY DEVER: And if
I could just add, so this is for us where
the real value occurs. So I mentioned
before, around systems having rule sets
to calculate GST, we see time and time again the
system doing its job perfectly. And what I mean by that
is, when the code is hit that says this is a
tax rate claimable expense, everything works. The problem is, if
you’re leaving it to an employee or an
accounts payable clerk to rely on that first decision
to get the categorization right, then that’s
where the risk occurs. And so, what this solution does
is it scans the source document and works out from the source
document based on the ML model it sits behind what
kind of expense it is and is it classified
as a recoverable expense or a non-recoverable expense. So that gap where you’re relying
on a non tax-trained person to make a tax call goes away. And that’s where we see
the real value here. EDWARD KNUST: And as
business processes have become more and more
outsourced and more and more removed from the
business, that’s how misclassification is
happening more and more often. So I’ll run you through just the
last couple of examples here. I want to show you
a standard invoice– so one we looked at before. So as I mentioned
earlier on, all of the relevant requirements for
a valid tax invoice are here. So the solution has deemed
the invoice to be valid. It’s a domestic invoice. It’s capable of full
VAT or GST recovery because here it’s
a hotel invoice. It’s a valid business spend. So you’ll see here that the
VAT spend has been identified, and the VAT claimable
has been identified as exactly the same amount. So this is where we would
expect the vast majority of our clients’
invoices, this category, to fall into, where you
do have a valid document and you’re
auto-calculating the tax. But to Brady’s
earlier point, you’re getting the surety that,
on each and every occasion, the system is working correctly
rather than applying a default rule. And the last one
I want to show you is where the real intelligent
part of that second ML model is coming in. So this is where we have
an entertainment expense. So here, we’ve got an invoice
or a receipt from a restaurant. The value shows that
it’s not subsistence. I may or may not have
participated in that event. It looked like it
was a good one. So here, that logic that’s
applied within the ML model of looking at the
vendor type, of looking at the spend, the
location has been able to determine that, rather
than being a general expense, this is an expense of
an entertainment nature. Now, entertainment typically
in most VAT jurisdictions has a restricted recovery
because the tax office doesn’t want you to be able
to go out and have a high-value lunch or dinner
and claim all the tax back. So here, we’ve identified that
it falls within that category. It is a valid document. So when it comes to the
VAT claimable amount, we’ve been able to apply
the relevant local rule for restriction. So the VAT spend amount is
double what the VAT claimable bill amount is because we only
have a 50% right to recovery of entertainment expenses. This, again, is one of
those scenarios where if you’re an AP clerk
or an individual trying to do a classification in
an expense type which is not subject to full recovery,
that gets very, very tricky. So the ML model that
sits behind this has been trained
for years by PWC to do expense type
classifications both for indirect taxes,
corporate, and other taxes. And so, we’re able to apply it
here to do that classification, and we can use the same expense
classification methodology in any country that has
a differentiation on tax credit of different
expense types incurred. BRADY DEVER: So what we’ve
done here in Australia is really just
categorize down to what we would call the lowest common
denominator from a GST recovery perspective. And we need to go deeper
and deeper depending on what the business is. So for example, financial
services entities in most VAT jurisdictions have
a really complex VAT recovery profile on purchases. And so, the Swift
classification logic– the PWC classification
logic– that is deployed into
the Google ML model enables us to categorize,
just like what you saw on that
entertainment expense, to look at the individual
description of the line on the invoice, apply
business rules against that to understand what
kind of expense it is and who’s incurring it and
in what cost center and what department, and then apply
categorisation logic which then tags to a GST
or VAT result. OK? So that’s where the tax
smarts really kick in and where the ML models
really, really serve us well, because we can access
hundreds of thousands or millions of
similar transactions posted by all of
our other clients– obviously, in a fully-sanitized
way to deal with privacy– to then effectively
come back out with a suggested classification
and categorization, which is really, really powerful
because, effectively, what we’re now doing is moving away
from rules-based tax decisions to model-based tax decisions,
which is really exciting. EDWARD KNUST: So that’s
the end of the demo. We thought we
would then take you through where we’re going
to take the solution over the next couple of years. So the product development
roadmap for the rest of 2019, as we discussed earlier, we
finished the proof of concept earlier this year. We’ve now gone live with this
as a live client solution within Australia. We’re very quickly
localizing the solution in additional jurisdictions. This will be our
global solution, so we’re moving very quickly. I’ll talk about those
locations in the next slide. And next, as I mentioned
earlier, the API configuration to expense management systems
we see as key in the short term because, typically,
our clients really struggle with the
extraction of data– so being able to have APIs into
the main expense management systems, including the SAPs,
SAP Concur, Oracle, et cetera. All of those main
expense systems will be looking to
configure into their APIs. And UI enhancement, as pretty
as this looks or did look, we’re very conscious
that clients do want value-added
analytics and reporting. As Brady was mentioning earlier,
if you think about the expense classification analysis
that we’ve been able to do, some of our clients
have talked to us about using that for
broader management reporting because a lot of them don’t
have visibility themselves over the different
classifications of expense spend or potentially
misclassifications. So broader use cases we’re
looking into as well. So I’ll move onto our
localization strategy. BRADY DEVER: Sorry. I know this back and
forth probably isn’t– we should have really prepared
for the back and forth. I apologize. The one thing I just
going to add was the API and configuration
into the ERPs– and I kind of touched
on it earlier– really, really critical
for us because this is one part of a broader
compliance process stream for tax. So we’ve got calculation
in the system. And then, that data then
moves into reporting suites. And SAP and Oracle in particular
are developing their capability around tax reporting and
filing out of the ERP as opposed to extraction
and then filing via a third-party solution. And so, what this is
really, really exciting about is this enables
end-to-end automation. And PWC actually
is working with SAP as well to build tax reporting
solutions inside of the ERP to do the filing to
the regulator, some of the post-filing analytics
and reconciliations and trending and variance testing. And so, by having backend
automation inside of the ERP to do tax compliance
and reporting combined with tax calculation at
the frontend, all inside of the system, is a really,
really exciting prospect for us. And it’s enabled by GCP
and Google AI and ML through the collaboration
that PWC, SAP, and Google are partaking in at the moment. So really, really
exciting times. Sorry. EDWARD KNUST: That’s all right. So our localization strategy. We’ve said in Australia. We’re sort of heading
northwest through the world. We’re localizing for
three different reasons. So the strategy is driven by
the complexity of tax rules. So we certainly
believe that we should tackle complex
jurisdictions early because, if you can do it
in complex jurisdictions, you can do it in anywhere. And the EU and
Canada are examples of particularly
complex jurisdictions. So those localizations
are already underway. The value of tax at stake. Clearly, our clients
want us to localize where they have the biggest
tax risk or biggest tax amount sitting on the
table not being collected. So an example of that in the
Asia-Pac region is Singapore. So Singapore is the hub for
firms in the region which have a VAT and GST. Hong Kong does not. So Singaporean-based clients are
very keen to get this solution, so we’re localizing there. And India is an example of
where you have very complex local country validation rules. So the process for claiming
tax credits based on invoices in India is very complex. So we’re localizing
there as well. So by localizing in those
different countries which have those different
complexities and requirements, we’re confident
that we will then have a product which is
truly globally capable based on those first five countries. And certainly, we’re
looking to replicate what we’ve already done
from global VAT reporting automation– for which we’ve had a
solution in place for a number of years– into this upstream source system
classification, validation, and calculation. So we’ll finish just
on future use cases, and I’d be keen to
hear anyone’s ideas because we’re always
open to new ideas. Our clients are always
challenging us with new ideas. So the obvious one to us is
any other tax applications where the underlying
document is relevant for tax classification. So here, we’re talking about
withholding tax, stamp taxes, sales taxes, you’re having
to make an OPEX versus CAPEX decision which has a tax impact. Any of these taxes which rely
on a document for calculation and validation are
prime candidates, and our clients are
asking us to build those. More broadly, in finance process
automation, many of our clients are going through those
Cloud ERP upgrades– [INAUDIBLE]
upgrades, et cetera– and this is the
perfect time for them to do that last
leg of automation, which isn’t necessarily
available within those Cloud ERP suites. And thirdly, broader
business process automation. I mean, the sky’s the limit. Anything within a business
process, which involves someone having to use a document to make
a decision or a classification or a validation Zipline
can be applied to. So we’re keen to
get the core use case bedded down and localized
across those five countries, but we really see the ability
to have multiple streams and multiple different
use cases of Zipline in the very near future. BRADY DEVER: And I think it’s
useful to call out in two and three, in particular– well,
across all of those three use cases– these are real
examples of clients in the very, very
early embryonic stages of this project that
are starting to ask us, could it do this,
could it do that? And so, we’ve had clients ask
us about withholding taxes. We’ve got one client,
we were actually doing an augmentation of
this to do accounts payable processing– so to actually
process the expense and replace the existing process
altogether, not just do the tax calc. Really exciting stuff,
particularly when you see the cost of
invoice processing, which I think we had on one of our
earliest slides of around $5 US an invoice. The other thing that
we’ve started to do is work together with some of
our own forensics and analytics teams outside of
tax, and we’re doing things in terms of
complementing some existing processes around loan
document analysis for banks, expense fraud
analysis just given that the power of the data that
we’ve got in this model. And so, yeah. Really, we see this is as a
little, humble indirect tax solution that has much,
much greater application outside of indirect taxes and
huge potential for our clients. [MUSIC PLAYING]

Leave a Reply

Your email address will not be published. Required fields are marked *