Is anyone using Docstar for AP invoice automation and specifically to perform a 3 way match? We have started implementing Docstar and it works ok for bringing an invoice in and posting but it doesn’t check that the PO was approved and that all of the items was received. We need to get more devlopment work done to achieve that
I was wondering if anyone else had done this and its working for them. The issue that strikes me is that with a lot of items we buy we have different product codes to the supplier or only descriptions may be used.
When we receive an invoice in to Docstar it should 1) check the PO is approved 2) Check that each line and quantity has been received in to the business through receipt entry. If it meets these checks it can post to the system. If it fails any of these checks it either needs to go to the person who raised the invoice for approval or keep retyring the match until it can complete
Docstar as we have it will not do this. It will post the invoice without check and the invoice lines will be Misc receipt lines rather than received and matched receipt lines
Did you purchase the pre-built AP Automation workflow or design one yourselves?
I’m in the early stage of development/implementation, and we bought the pre-built version. It was explained to me that in order to do much work with the lines, you would need to do more work in the workflow and buy an additional license to OCR them specifically. But it is supposed to check that it was fully received and that the dollar amounts received total out to be the same as the PO, otherwise it will push it to a queue for manual approval.
It doesn’t check the individual line items, just the total received value for a Receipt that matches the PO Number on the Invoice (that was found when DS brought in the invoice). And then just copies those received line from the receipt to the invoice I think…
We’re doing training on the workflow itself on Monday and running some test cases through there.
(Ping me next week when I know more )
We’re also working on a similar workflow to bring in the receiving documents (via a Scanner/Copier on the docks) and find/file by the PO Number and then prevent the AP Invoice import unless there are actual receiving documents.
Mike, we did purchase the pre built AP automation workflow and used an Epicor consultant to help implement it and I believe we should have the appropriate OCR license. We are using a cloud hosted instance of DocStar and the new Ancora OCR platform
For us it doesnt seem to do any checking about the PO and receipt. It can identify a PO number on the invoice and use the appropriate PO/non-PO workflow but doesnt check anything after that. The user can complete the invoice and submit to Epicor regardless of what is received. Checking value I guess is fine but we do get lots of part receipts so have to check line level
I just wanted to check in with other users to see what they are doing. It seems that you have what we need and what we asked Epicor to implement
I don’t know that is true. I know what was explained to me, but we’re not going through the workflow until Monday - and t hen I’ll know more. I’m now leaning towards “I don’t have what both of us need”.
Let’s cycle back around on this next week after we both find out more and share notes.
@MikeGross We are mid implementation and only have IDC and the programmer is working with me to do the workflow and I am doing custom fields to help them thru the process. I won’t see where we are until December, but it seems that what was scoped out will do our processing and exceptions.
I am curious to hear what your feedback is once you see the workflow.
There are a several different offerings of the DocStar ECM AP Automation solution. It may include Intelligent Data Capture (IDC) or not and the Intelligent Data Capture may capture Header/Footer data only or it may capture Header/Footer and Line Item detail as well. In order to perform a 3-way match at the Line level, Line Item capture is necessary. Once you have the Line Item Capture engaged, int eh IDC PO Invoice workflow line items are compared in a 3 way match by default. The Invoice Line Item is compared to ‘Uninvoiced Receipt Lines’ for the specified PO number. The PO must be Approved in order to receive against it and the lines must be received and not yet invoiced in order to even perform the match. What i think was being described earlier in this thread was the non-PO Invoice Workflow that only creates a single Misc line for the Invoice and does not match against the PO. Otherwise, the standard workflows may have been modified to behave differently. You can verify these details with your Implementation team but you can certainly accomplish the 3-way match you functionality you are looking for with DocStar ECM if you have the right pieces.
Have you seen how it is performing at a line level? I imagine all of the invoices coming from your vendors don’t all look the same at a line level… Is this working for you at the line level?
Hi, I am actually the Director of Product Management for DocStar ECM. Having many different Vendor Invoice formats is the reason why the Intelligent Data Capture (IDC) component is necessary. It processes all the different formats and uses advanced algorithms to identify the key information on varying invoice formats and ‘normalizes’ them into a standard format that then continues on to a 3 way match and business rule/exception processing to ultimately become an invoice entry in E10.
@remirzian - first, thank you for being here with us and willing to provide assistance to us. Second, I’m sure I’ll be reaching out once I get my head around our workflow in our training session on Monday.
So, we got lost in some other admin training topics, but we talked about it briefly. So, it will not READ the line items on the image of the receiving paperwork (packing list,etc.), not will it read the line items on the Supplier’s Invoice - both of these require the additional OCR license AND modification to the Workflow.
What it does do is figure out our PO#, then look up the received lines in Epicor and if the $$ amounts match, it will create the payable automatically - if they do not match it goes into the approval queue stage in the workflow.
We didn’t get in to the details or see the flow in action - I think we have that planned for Wednesday afternoon.
What you probably saw was the 2-way match - this is what we’re live with. It does what you say, if the received lines in Epicor add up to the total of the invoice, then it “matches”. The received lines within Epicor take their price from the PO anyway - so in my head I’ve checked the value across PO, receipts, and invoice.
The workflows are so flexible - we’ve changed them a fair bit to do additional checks. We have a 5k limit, after which our FD wants to review the document. All handled in the workflow, but it’s more than a simple value limit check. There are certain suppliers where we’re spending way more than 5k each week, so what I actually have is a UD field on the Supplier account with possible options of: null / Always Require Approval / Never require approval. Hopefully each is self explanatory.
You’ve got the main man @remirzian already on this post, which is great - he’s superb.
Thanks @markdamen - that all sounds right and close to what we’ll end up doing. For now we’re finishing mapping out users/group/doc-types/etc. and working on some training material.
Are you using Artsyl for capture/COR/workflow? I was surprised though at how much is really done with Artsyl and the recognition station versus inside DocStar (as far as automatic processing via email and hot folders, and OCR). In our case it seems our folks will spend a lot of time in Artsyl ‘training’ the system for a year or so until we can get the bulk of the invoices processed through the Artsyl workflow automatically and exported/imported into DocStar.
Yeah we use Artsyl, or docAlpha. It’s one area I keep meaning to double back and check on - my users won’t put their hand up and say that they are having to teach it the same invoice multiple times, they would just plod along. I want to check that the learning part of it is working as intended. You say a year, but in reality if you purchase from most of your suppliers monthly or quarterly, then it will be much less. Also, the standard one does a good job of picking up the required fields. The ones I have personally had to teach it, are the invoices where I sit and wonder what’s going on for a while because it’s in multiple currencies, and the VAT is shown in GBP but the rest of the invoice is in EUR - stupid things like that, sit there cussing the supplier!
The docAlpha bit if it’s working well is just looking to capture: InvoiceNum, InvoiceDate, SupplierName, SupplierID, SubTotal, Tax, Total. We supplemented this with Description, so that for Non-PO invoices the AP guys can put a description in at the docAlpha stage and it goes straight through to the relevant budget holder inside docStar for coding to the correct GL.
That reminds me, that was another custom field on the Vendor - to hold the username of the person within E10 that it should be routed to. DocStar does a lookup from VendorID, to find that username, and then look that up for a docStar user to route to.
Good to know you are using it too. And I’ve already come across a whole group of invoices that seem like they will never be automatic, so I’ve been doing a bit of cussing as well.
We’re discussing the ‘routing’ tomorrow b/c we’ve got a complicated approval process (that doesn’t need to be complicated) and I’m not sure how to best modify the workflow in DocStar.
Once we get back into the training of docAlpha, I may need to reach out again… btw - might you have a training doc I could plagiarize to get a leg up on creating one for our folks?
@MikeGross@markdamen
I gave my installer 500 invoices from all of our vendors and he trained the system from them. Is there more training to be done later or only for new vendors?
)