ကူးယူချက် 🔗
WEBVTT
00:00:04.719 --> 00:00:21.199
If your business is already implemented in voicing, your team is filling with corrections and consistent data work about this or uncertainty about whether the process is really working, this podcast is for you.
00:00:21.600 --> 00:00:31.120
I'm done linking and I help businesses look beyond a successful submission to the data, processes, and controls behind e-invoicing.
00:00:31.519 --> 00:00:36.000
Because validation does not always mean everything is correct.
00:00:36.640 --> 00:00:43.520
Today's episode is about the most expensive e-invoice gaped maybe outside your software.
00:00:43.840 --> 00:00:44.960
Imagine this.
00:00:45.280 --> 00:00:51.359
Your finance manager tells you, everything is working, the software is connected.
00:00:51.600 --> 00:00:54.159
Our e-invoices are going through.
00:00:54.479 --> 00:00:56.560
They are being validated.
00:00:56.960 --> 00:01:02.079
As a business owner, that probably sounds reassuring.
00:01:02.399 --> 00:01:05.280
You have spent money upgrading the system.
00:01:05.519 --> 00:01:08.480
Your accounts team has attended training.
00:01:08.719 --> 00:01:11.040
Invoices are being transmitted.
00:01:11.280 --> 00:01:15.280
There are no major system errors appearing on the screen.
00:01:15.599 --> 00:01:21.840
So naturally you may conclude our e-invoice implementation is working.
00:01:22.079 --> 00:01:24.319
But then something happens.
00:01:24.560 --> 00:01:31.920
A customer calls because information on an invoice is not what they expected.
00:01:32.239 --> 00:01:34.159
Finance checked the system.
00:01:34.799 --> 00:01:37.760
The invoice was submitted successfully.
00:01:38.079 --> 00:01:42.000
The system did exactly what it was supposed to do.
00:01:42.239 --> 00:01:44.959
So where did the problem come from?
00:01:45.439 --> 00:01:55.040
Finance starts tracing the transaction backwards and they discover that the problem did not begin in accounting software at all.
00:01:55.280 --> 00:02:02.239
Perhaps sales agreed to a special arrangement but did not communicate it clearly.
00:02:02.480 --> 00:02:06.799
Perhaps customer information came from an old record.
00:02:07.359 --> 00:02:11.280
Perhaps one branch followed a different procedure.
00:02:11.520 --> 00:02:19.439
Perhaps an approval was given through WhatsApp, but nobody updated the person preparing the invoice.
00:02:19.680 --> 00:02:27.360
Or perhaps everyone involved assumed that somebody else had already checked the information.
00:02:28.000 --> 00:02:31.199
That is the issue I want to discuss today.
00:02:31.439 --> 00:02:38.639
Because one of the most important e-invoice implementation gaps may be sitting outside your software.
00:02:38.960 --> 00:02:53.919
Software can process the information your organization gives it, but software does not necessarily know whether your organization has misunderstood the transaction before the information reaches the system.
00:02:54.319 --> 00:02:57.039
And this distinction matters.
00:02:57.360 --> 00:02:59.840
There are really two questions.
00:03:00.159 --> 00:03:04.800
The first question is, can your system submit an e-invoice?
00:03:05.039 --> 00:03:14.240
The second question is, does the business process producing that e-invoice consistently produce the right information?
00:03:14.560 --> 00:03:16.800
Those are not the same question.
00:03:17.120 --> 00:03:22.719
A business can answer yes to the first question and still have problems with the second.
00:03:23.360 --> 00:03:25.120
Think about an iceberg.
00:03:25.759 --> 00:03:30.319
What you see on your screen is the part above the water.
00:03:30.960 --> 00:03:44.080
You see the invoice, you see the required fields, you see whether it has been submitted, you see whether it has been validated, and you see obvious system errors.
00:03:44.400 --> 00:03:48.240
But underneath the invoice is a much bigger process.
00:03:48.560 --> 00:03:51.039
Who agreed the commercial terms?
00:03:51.360 --> 00:03:53.680
What triggered the invoice?
00:03:53.919 --> 00:03:56.879
Where did the customer information come from?
00:03:57.280 --> 00:04:00.800
Who decided how the transaction should be treated?
00:04:01.120 --> 00:04:02.479
Who approved it?
00:04:02.719 --> 00:04:08.240
How did the information move from sales to operations and then the finance?
00:04:08.800 --> 00:04:11.599
What supporting documents were retained?
00:04:11.840 --> 00:04:15.599
And what happens when transactions is unusual?
00:04:15.919 --> 00:04:18.879
That is the part management may not see.
00:04:19.199 --> 00:04:22.720
The invoice is only the final visible output.
00:04:22.959 --> 00:04:26.959
The process that created it is much larger.
00:04:27.439 --> 00:04:30.480
Let me give you a composite example.
00:04:30.800 --> 00:04:38.399
Imagine an SME that sells equipment and also provides installation and maintenance services.
00:04:38.720 --> 00:04:42.720
The company upgrades its accounting software for e-invoicing.
00:04:43.040 --> 00:04:46.079
Finance attended the system training.
00:04:46.399 --> 00:04:49.759
Test invoices are submitted successfully.
00:04:50.079 --> 00:04:53.120
Standard equipment sales work quite well.
00:04:53.439 --> 00:04:59.120
Management therefore believed implementation is largely complete.
00:04:59.600 --> 00:05:07.279
But then somebody looks beyond the standard sales invoice and suddenly the picture becomes more complicated.
00:05:07.600 --> 00:05:12.879
Sales representatives sometimes collect deposits before orders are finalized.
00:05:13.199 --> 00:05:18.639
Installation teams confirm completion through messaging applications.
00:05:18.879 --> 00:05:23.439
Maintenance contracts are built according to different schedules.
00:05:23.759 --> 00:05:28.319
Branches submit billing information through spreadsheets.
00:05:28.639 --> 00:05:32.240
Managers approve special discounts through email.
00:05:32.560 --> 00:05:36.399
Refunds are handled outside the normal sales
Load full transcript
process.
00:05:36.560 --> 00:05:42.480
And credit notes request do not always follow the same approval route.
00:05:42.720 --> 00:05:49.360
Now ask yourself, which one of those activities is the accounting software supposed to fix?
00:05:49.680 --> 00:05:50.800
It cannot.
00:07:30.160 --> 00:07:35.120
And fourth, what do employees actually do every day?
00:07:35.439 --> 00:07:39.680
If those four questions are different, there may be a gap.
00:07:40.000 --> 00:07:46.879
For example, management may say, of course customer information is verified before invoicing.
00:07:47.199 --> 00:07:48.480
That sounds good.
00:07:48.800 --> 00:07:50.959
Then you look at the procedure.
00:07:51.199 --> 00:07:55.839
The procedure says sales is responsible for checking the information.
00:07:56.160 --> 00:07:57.839
Then you speak to sales.
00:07:58.160 --> 00:08:02.240
Sales says, no, finance normally checks that.
00:08:02.720 --> 00:08:04.319
Then you speak to finance.
00:08:04.639 --> 00:08:10.480
Finance says, we normally use whatever information is already in the system.
00:08:10.720 --> 00:08:15.199
If something is missing, we search through all emails.
00:08:15.439 --> 00:08:18.399
Now you have discovered something important.
00:08:19.279 --> 00:08:22.480
You don't necessarily have a software problem.
00:08:22.800 --> 00:08:25.120
You have an ownership problem.
00:08:25.439 --> 00:08:33.200
Nobody is completely clear about who is responsible for verifying the information before it reaches the invoice.
00:08:33.360 --> 00:08:39.679
And that distinction is important because different problems require different solutions.
00:08:40.000 --> 00:08:46.080
If the problem is ownership, buying another piece of software may not solve it.
00:08:46.399 --> 00:08:52.559
If the problem is system integration, writing another SOP may not solve it.
00:08:52.799 --> 00:08:58.399
If the problem is staff knowledge, changing the workflow alone may not solve it.
00:08:58.559 --> 00:09:08.720
And if the problem requires text or professional interpretation, simply telling employees to follow the procedure may not solve it either.
00:09:09.039 --> 00:09:12.000
The solution has to match the gap.
00:09:12.720 --> 00:09:22.799
Now, if you are listening as a business owner or finance person, there are a few warning signs I would pay attention to.
00:09:23.279 --> 00:09:30.720
Does finance regularly have to correct information received from other departments?
00:09:31.360 --> 00:09:40.000
Do unusual transactions always have to go to one experienced employee because nobody else knows what to do?
00:09:40.799 --> 00:09:45.120
Do different branches follow slightly different procedures?
00:09:46.240 --> 00:09:54.320
Does billing sometimes stop while people search through emails or WhatsApp messages for supporting information?
00:09:54.799 --> 00:10:01.200
Are spreadsheets sitting between your operational system and your accounting records?
00:10:01.519 --> 00:10:09.679
When an e-invoice has to be corrected, does your team simply fix that one invoice and moved on?
00:10:10.240 --> 00:10:14.399
Or does someone ask, why did this happen?
00:10:14.559 --> 00:10:18.000
And is the same thing happening elsewhere?
00:10:18.320 --> 00:10:26.000
That last question is particularly important because correcting an individual error solves today's problem.
00:10:26.480 --> 00:10:31.039
Understanding why the error occurred may prevent tomorrow's.
00:10:32.000 --> 00:10:40.879
And this is why the most expensive implementation gap may not be the one that immediately causes a rejection.
00:10:41.120 --> 00:10:44.159
A rejected transaction gets attention.
00:10:44.480 --> 00:10:45.759
Something stops.
00:10:46.080 --> 00:10:47.919
Someone investigates it.
00:10:48.159 --> 00:10:53.279
A hidden operational gap can be more difficult because everything continues.
00:10:53.600 --> 00:11:08.240
Invoice continue to be issued, the system continue to work, people continue using their usual workarounds, and nobody realizes that the same weaknesses is repeating in the background.
00:11:08.399 --> 00:11:34.000
The cost may show up gradually, more corrections, more staff time, delayed billing, delayed collection, customers dispute, different treatment of similar transactions, difficulty explaining what happened six months later, or disruption when the one employee who understand the workaround is on leave.
00:11:34.399 --> 00:11:36.639
This is an important point here.
00:11:36.879 --> 00:11:44.320
The total cost of an implementation weaknesses is not confined to regulatory exposure.
00:11:44.559 --> 00:11:52.320
It can also involve reworked, interrupted cash flow, management time, and customer confidence.
00:11:52.639 --> 00:11:56.320
So here is today's clarities check.
00:11:56.639 --> 00:12:02.559
Choose one transaction in your business, not necessarily your easiest transaction.
00:12:02.960 --> 00:12:23.679
Choose one that involves several people or department, perhaps a deposit, a refund, a credit note, a special discount, a cross-border transaction, a transaction come through a branch, or something your team regularly describe as this one is a little different.
00:12:24.080 --> 00:12:28.080
Then follow the transaction from beginning to end.
00:12:28.639 --> 00:12:30.080
Ask four questions.
00:12:30.720 --> 00:12:34.799
What does a management think should happen?
00:12:35.440 --> 00:12:39.440
What does the documente procedure say should happen?
00:12:39.679 --> 00:12:43.360
What do the employees involved actually do?
00:12:43.600 --> 00:12:47.759
And what do the applicable requirements expect?
00:12:48.080 --> 00:12:50.399
Then look at the differences.
00:12:50.879 --> 00:12:59.120
You may discover your biggest e-inverse issue has very little to do with whether your software can transmit the document.
00:12:59.360 --> 00:13:02.960
It may be sitting three steps earlier in the process.
00:13:03.200 --> 00:13:12.480
And this is why my 3C framework deliberately begins with clarifying, then consistent, and finally controlled.
00:13:12.720 --> 00:13:14.399
The sequence matters.
00:13:14.639 --> 00:13:21.279
Because if you standardize before you understand the gaps, you may simply standardize the wrong process.
00:13:21.440 --> 00:13:30.799
And if you automate before you clarify the assumption behind the process, you may simply allow those assumptions to move faster.
00:13:31.120 --> 00:13:42.799
So the principle I want you to remember from this episode is do not automate an assumption, do not standardize an unidentified gap.
00:13:43.279 --> 00:13:45.120
Create clarity first.
00:13:45.519 --> 00:14:03.759
If today's discussion sounds familiar, perhaps your software is working, but your team is still correcting transactions, chasing information or handling exception differently, then the next question is not necessarily do we need better software?
00:14:04.080 --> 00:14:09.039
The better questions may be where is the gap actually coming from?
00:14:09.919 --> 00:14:25.440
That is exactly the kind of issue I work on through my e-invoice implementation coaching, helping businesses examine the process, people, data, and responsibility sitting behind the technology.
00:14:25.759 --> 00:14:29.360
Before you go, here is your clarity question.
00:14:29.600 --> 00:14:34.080
Is e-invoicing genuinely under control in your business?
00:14:34.240 --> 00:14:38.240
Or is your team simply fixing the problems as they appear?
00:14:38.480 --> 00:14:44.159
If you are not sure, start with my complimentary business clarity channel.
00:14:44.399 --> 00:14:47.360
You will find the link in the episode description.