TRANSCRIPT 🔗
WEBVTT
00:00:04.719 --> 00:00:21.359
If your business is already wishing, correctness consistent data workouts or uncertainty about whether the process is really working, this podcast is for you.
00:00:21.519 --> 00:00:31.359
I'm Dunley and I help businesses look beyond 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.880 --> 00:00:42.799
Why e-invoicing confusion persists even after your software is live?
00:00:43.119 --> 00:00:46.000
And what owners should clarify first?
00:00:46.320 --> 00:00:49.200
This is the topic we're going to discuss today.
00:00:49.600 --> 00:00:52.159
Your e-invoice software is live.
00:00:52.640 --> 00:00:54.960
Invoices are being submitted.
00:00:55.280 --> 00:00:57.920
The accounting team has been trained.
00:00:58.159 --> 00:01:02.240
Some documents have already been validated successfully.
00:01:02.560 --> 00:01:08.560
So as a business owner, you may reasonably expect the confusion to reduce.
00:01:09.120 --> 00:01:12.079
But instead, questions keep coming back.
00:01:12.640 --> 00:01:15.439
Should we issue an e-inverse for this?
00:01:16.000 --> 00:01:18.400
Who should appear as the buyer?
00:01:18.879 --> 00:01:21.519
What happens with the deposit?
00:01:21.840 --> 00:01:25.599
Is this reimbursement treated the same way?
00:01:26.159 --> 00:01:29.439
Why does this branch handle it differently?
00:01:29.840 --> 00:01:34.079
Why is finance still correcting information before submission?
00:01:34.799 --> 00:01:44.239
At some point, an owner may start wondering, if the system is already working, why are we still confused?
00:01:44.799 --> 00:01:57.760
The answer is that going live with the software does not automatically mean the business has clarified how e-invoicing applies to the way it actually operates.
00:01:58.159 --> 00:02:01.439
That is the distinction I want to explore today.
00:02:01.680 --> 00:02:10.879
Because for many businesses, the problem after go live is no longer can our software submit an e-invoice?
00:02:11.120 --> 00:02:17.680
The problem becomes do we understand what should happen before the software submits it?
00:02:18.319 --> 00:02:24.639
Imagine a business that has successfully implemented its e-invoice software.
00:02:24.960 --> 00:02:27.199
Standard sales are going through.
00:02:27.520 --> 00:02:30.800
Finance understands the basic submission process.
00:02:31.120 --> 00:02:34.960
Management believes the difficult part is over.
00:02:35.520 --> 00:02:38.639
Then a customer pays a deposit.
00:02:38.960 --> 00:02:41.919
Someone asks finance what to do.
00:02:42.240 --> 00:02:44.479
Finance gives an answer.
00:02:44.879 --> 00:02:49.360
The following week, another deposit arises through a branch.
00:02:49.599 --> 00:02:52.080
The branch handles it differently.
00:02:52.400 --> 00:03:01.680
Later, sales agree to a special arrangement with a customer, but finance only finds out when the invoice is being prepared.
00:03:02.319 --> 00:03:04.159
Then there is a refund.
00:03:04.560 --> 00:03:09.360
Then an overseas suppliers, then an employee reimbursement.
00:03:09.599 --> 00:03:14.879
Suddenly the questions do not feel like software questions anymore.
00:03:15.199 --> 00:03:17.360
That is because they are not.
00:03:17.919 --> 00:03:21.280
There are questions about the transaction itself.
00:03:21.520 --> 00:03:28.000
And that is one reason confusion often survives the technology implementation.
00:03:28.240 --> 00:03:32.560
Software works best when the rule is already known.
00:03:32.879 --> 00:03:55.120
If the business knows what transaction has occurred, who the parties are, when the transaction should be recognized within the e-invoice process, what information is required, and what happens when something changes, then the technology has something clear to process.
00:03:55.360 --> 00:04:01.840
But when those methods are uncertain, the software does not remove the uncertainty.
00:04:02.159 --> 00:04:07.919
It may simply process whichever assumption was entered into it.
00:04:08.400 --> 00:04:17.040
That is why a technically functioning system can sit inside a business that is still operationally confused.
00:04:17.680 --> 00:04:24.319
The software can be live while the operating understanding behind it is still incomplete.
00:04:24.560 --> 00:04:27.600
There is another reason confusion persists.
00:04:27.839 --> 00:04:32.240
Different departments see different parts of the same transaction.
00:04:32.560 --> 00:04:36.399
Sales may understand what was agreed with the customer.
00:04:36.720 --> 00:04:41.839
Operations may know whether the job has actually been completed.
00:04:42.160 --> 00:04:47.519
Finance may understand what has been entered into the accounting system.
00:04:47.759 --> 00:04:52.240
Management may know why a commercial exception was approved.
00:04:52.560 --> 00:05:03.040
IT may know how the system has been configured, but no single department necessarily sees the whole transaction from beginning to the end.
00:05:03.439 --> 00:05:05.199
That creates a problem.
00:05:05.680 --> 00:05:12.480
Everyone can be correct about their own part and still have a gap between departments.
00:05:12.800 --> 00:05:20.240
For example, sales may say, we already told the customer they could pay 30% up front.
00:05:20.560 --> 00:05:26.319
Finance may say, we were never told that this transaction had a special arrangement.
00:05:26.639 --> 00:05:32.000
Operation may say, we thought billing only started after installation.
00:05:32.240 --> 00:05:35.360
The software does not resolve that disagreement.
00:05:35.600 --> 00:05:39.439
The confusion exists before the data reach the system.
00:05:39.839 --> 00:05:48.079
This is why I think business owners need to distinguish between technical confusion and business process confusion.
00:05:48.560 --> 00:05:54.319
Technical confusion sounds like why did the
Load full transcript
API reject this document?
00:05:54.639 --> 00:05:57.680
Why is this field not mapping?
00:05:58.079 --> 00:06:01.279
Why is the integration not transmitting?
00:06:01.600 --> 00:06:04.079
Those are system-related questions.
00:06:04.399 --> 00:06:07.439
Business process confusion sounds different.
00:06:07.759 --> 00:06:09.839
Who owns this information?
00:06:10.160 --> 00:06:14.480
When should this transaction enter the invoicing process?
00:06:14.959 --> 00:06:19.839
Why are two departments treating the same situation differently?
00:06:20.160 --> 00:06:25.199
What happens when the transaction does not fit our normal procedure?
00:06:25.519 --> 00:06:29.279
Who decides what to do when there is uncertainty?
00:06:29.519 --> 00:06:36.240
Those questions cannot always be solved by asking the software provider to configure the system.
00:06:36.639 --> 00:06:47.199
The underlying issue may be that the business itself has not yet reached a common understanding, and this leads to another source of confusion.
00:06:47.439 --> 00:06:57.040
Businesses often assume that because the e-invoice has been validated, the underlying process must also be correct.
00:06:57.439 --> 00:07:02.399
But validation and business understanding are not the same thing.
00:07:02.720 --> 00:07:10.560
A system can confirm that required information has been received in an acceptable format.
00:07:10.959 --> 00:07:18.480
That does not necessarily answer every question about why the transaction was treated in a particular way.
00:07:18.800 --> 00:07:21.120
For management, this matters.
00:07:21.439 --> 00:07:26.959
Because a document moving successfully through the platform may create confidence.
00:07:27.199 --> 00:07:45.279
But if finance is repeatedly correcting data from sales, if branches are using different practices, if one experienced employee handles every unusual transaction, or if staff regularly asked which option should I choose for this?
00:07:45.759 --> 00:07:54.079
Then the business may still have unresolved implementation issues even though submissions is technically working.
00:07:54.240 --> 00:07:57.120
So what should owners clarify first?
00:07:57.680 --> 00:08:03.439
Not every detail, and certainly not every feel inside the software.
00:08:03.759 --> 00:08:07.279
Start conceptually with three areas.
00:08:07.600 --> 00:08:12.560
The first is what transaction actually exists in our business?
00:08:13.199 --> 00:08:22.240
That sounds obvious, but businesses often think in terms of accounting documents rather than commercial activity.
00:08:22.959 --> 00:08:41.200
Standard sales may be straightforward, but what about deposits, refunds, credit notes, employee claims, cross-border purchases, intercompany charges, platform transactions, special customer arrangements.
00:08:41.519 --> 00:08:45.679
The point is not that every one of these creates a problem.
00:08:46.320 --> 00:09:00.159
The point is that an owner should know whether the business has transactions that
do not follow the normal sales and purchase path, because those are often where confusion first appears.
00:09:00.720 --> 00:09:06.720
The second area is who influences the information before it reaches finance?
00:09:06.960 --> 00:09:12.480
If sales collects customer information, sales affecting e-invoicing.
00:09:12.799 --> 00:09:20.240
If operations determine when work is complete, operations affect e-invoicing.
00:09:20.399 --> 00:09:26.960
If procurements negotiate suppliers arrangements, procurement may affect e-invoicing.
00:09:27.120 --> 00:09:32.879
If branch staff collect deposits, branches may affect e-invoicing.
00:09:33.360 --> 00:09:40.480
This is why treating e-invoicing as a finance-only responsibility can create blind spots.
00:09:40.799 --> 00:09:52.320
Finance may be the department submitting the documents, but finance is often receiving information that was created, changed, or approved somewhere else.
00:09:52.559 --> 00:10:04.639
So when owner asks why finance is struggling after go life, the answer may be because finance is dealing with the consequences of decision made outside finance.
00:10:05.279 --> 00:10:10.879
The third area is where does the standard process stop being enough?
00:10:11.279 --> 00:10:15.039
This may be the most important questions.
00:10:15.840 --> 00:10:24.159
A good operating process handles routine transactions efficiently, but not every transaction is routine.
00:10:24.720 --> 00:10:27.679
Sometimes the parties are unusual.
00:10:27.840 --> 00:10:30.799
Sometimes the payment timing changes.
00:10:31.039 --> 00:10:35.759
Sometimes money moves before the transaction is complete.
00:10:36.000 --> 00:10:39.200
Sometimes a foreign party is involved.
00:10:39.440 --> 00:10:44.399
Sometimes an adjustment happens after the original e-invoice.
00:10:44.639 --> 00:10:50.639
Sometimes the business simply has not encountered that situation before.
00:10:50.960 --> 00:10:57.679
The owner does not need to personally know the technical answer to every one of those questions.
00:10:58.000 --> 00:11:06.080
But management should know that some transactions require clarification before they are treated as normal.
00:11:06.480 --> 00:11:09.600
That is a very special capability.
00:11:10.399 --> 00:11:17.120
This is where my 3CE invoice implementation frameworks begins with clarifying.
00:11:17.440 --> 00:11:25.919
Before a business tries to make everything consistent, it needs enough clarity about what is trying to standardize.
00:11:26.240 --> 00:11:45.360
That means understanding the important transaction journeys, recognizing where the current process contains uncertainty, and identifying which matters require commercial, accounting, tax, legal or technical clarification.
00:11:45.759 --> 00:11:50.720
Only after that does consistency become meaningful.
00:11:51.039 --> 00:11:59.279
Because if the business standardizes an unclear process, it may simply make the confusion more repeatable.
00:11:59.679 --> 00:12:07.440
And if it automates an unclear assumption, the system may repeat that assumption faster.
00:12:08.000 --> 00:12:10.480
Here is today's clarity check.
00:12:10.799 --> 00:12:19.919
As a business owner, ask yourself, when my team is confused about e-invoicing, what are they actually confused about?
00:12:20.399 --> 00:12:23.840
Is it the software or is it the transaction?
00:12:24.159 --> 00:12:29.039
Are they asking how to enter something into the system?
00:12:29.519 --> 00:12:34.799
Or are they really asking what the transaction means and who should decide?
00:12:35.360 --> 00:12:39.200
Are the same questions appearing repeatedly?
00:12:39.440 --> 00:12:46.080
And do those questions tend to happen when responsibilities moves between departments?
00:12:46.399 --> 00:12:50.399
You do not need to solve everything from that exercise.
00:12:50.639 --> 00:12:58.480
But the answer can tell you whether the confusion is mainly technical or whether it sits deeper in the business process.
00:12:58.720 --> 00:13:02.799
And this is the point I want business owners to remember.
00:13:03.120 --> 00:13:11.360
It involves confusion after goal life does not automatically mean the software implementation has failed.
00:13:11.679 --> 00:13:17.840
It may mean the organization has reached the next layer of implementation.
00:13:18.320 --> 00:13:20.559
The technology is working.
00:13:20.879 --> 00:13:29.840
Now the business has to clarify how its real transaction, real people, and real decision fits around the technology.
00:13:30.080 --> 00:13:38.080
That is why e-invoicing should not be viewed as simply as a software project with a go live date.
00:13:38.399 --> 00:13:40.799
It is an operating process.
00:13:41.039 --> 00:13:46.639
And operating processes requires shared understanding.
00:13:46.960 --> 00:13:56.960
If the same question keeps coming back after your software is live, the first question may not be what else do we need to configure?
00:13:57.279 --> 00:14:01.519
It may be what have we not yet clarified?
00:14:01.840 --> 00:14:06.240
That is where better e-invoice implementation begins.
00:14:07.919 --> 00:14:11.600
Before you go, here is your clarity question.
00:14:11.919 --> 00:14:16.320
Is e-invoicing genuinely under control in your business?
00:14:16.480 --> 00:14:20.559
Or is your team simply fixing problems as they appear?
00:14:20.799 --> 00:14:26.320
If you are not sure, start with my complimentary business clarity chat.
00:14:26.639 --> 00:14:29.600
You will find the link in the episode description.