Square 9 offers a number of traditional OCR options, but also has options that leverage tooling in the areas of AI and ML. While more modern extraction tooling can be very good at decreasing setup time, it’s often not a complete solution. Customer’s may need to blend modern and traditional approaches for extracting data to form a complete / all encompassing data capture platform.
Square 9’s most recent offering in the AI extraction space, dubbed FTE, involves AI assisted extraction models that are largely application/document/form independent. FTE works off of two core constructs: Forms and Tables.
Forms
Forms in FTE can be defined as Key / Value pairs. For the more technical audience, Key / Value pairs are a common construct often used in programing and scripts. In the context of a document however, Key / Value pairs can take on new meaning.
Consider the remittance section of a W.B. Mason invoice:
In a traditional extraction model, users are generally less concerned about keys and focus exclusively on values. It would be very simply to create an OCR template that extracted values for Customer Number, Invoice Number, Invoice Date, and Total Due. As your capture needs expand however, this model becomes fragile. Variances in scan resolution might impact positioning, and most certainly, similar documents produced by other vendors will introduce differences in layout. Square 9’s GlobalCapture offers a number of tools to help with such discrepancies in a more traditional manner, whether it be through Marker Zones, pattern matching, etc. FTE takes a different approach.
Rather than using structured or semi-structured templates, FTE leverages the power of AI to make assumptions about the text on a page. Rather than requiring a user to identify via a template that “C8675309” is the customer number, FTE makes the assumptions automatically on behalf of the user. So in the AI assisted world, the OCR result wouldn’t be an arbitrary value “C8675309” that a user has told us should be inferred as Customer Number. Instead, the OCR result would resemble “Key: Customer Number, Value: C8675309”. The same pattern would hold true for all Key / Value pairs identified on the document. So in this case, you would expect to see results like:
"Key":Customer Number","Value":"C8675309" "Key":"Invoice Number","Value":"I59692155" "Key":"Invoice Date","Value":"02/11/2024" "Key":"Terms","Value":"Net 30" "Key":"Total Due","Value":"71.98"
While the OCR results are extremely good, success does require adherence to a pattern of some kind. In the case of FTE, each value is expected to have a descriptive key in it’s general vicinity. This does not mean keys and values need to be laid out horizontally, nor does it mean grid lines must be present in the document’s layout. It does however mean that for each value one cares to extract, there must in fact be a related key.
And example case where this may present as problematic might be in the upper left corner of the W.B. Mason example above. In this case, both a phone number and a website address are present below the logo and address block.
In this example, there are two possible outcomes:
Either the phone number, the website address, or both simply don’t extract.
One or both values extract, but do so with a Key of “Address Service Requested”.
In either case, extracting one or both of these data points is likely better served with an alternate method. Certainly a traditional zone extraction could be perform to collect these data points. Alternately, other use case specific tools like Transform AI (which is tuned specifically for invoices and receipts) looks very specifically for data points that might match phone numbers and website addresses regardless of the presence of a Key.