DocumentClassificationNode

DocumentClassificationNode looks at an image and says what kind of document it is - receipt, invoice, ID card, passport, whatever classes the model was trained on - and returns both the numeric class index and the class name. It's the one classifier in the pack that outputs a structured pair (INT + STRING) instead of a free-text string, which makes it the easiest to wire into branching logic.

If your pipeline touches real-world documents at all - scanning receipts, sorting ID scans, triaging paperwork photos - this is the node you'd reach for. It's also a decent demonstration of why a structured output beats a text blob: you can compare the INT against a constant in a Switch node and route the document to different processing branches, no string parsing required.

How it works

Same local transformer classifier as the rest of the family: image preprocessed, run through a HuggingFace image-classifier, top class wins. The difference is purely in the output format - you get the index and the label of the predicted document type, not a ranked list.

Inputs and outputs:

• image - the IMAGE to classify.
• INT - the predicted class index (the model's internal category number).
• STRING - the human-readable class name ("receipt", "passport", ...).

Feed both out and pick whichever you need downstream. The INT is the one that's stable for logic - the model's class numbering is fixed, so a hardcoded "if index == 3" check survives label wording changes. Use the STRING when you want a human to read the result.

Where it's useful

The realistic case is document-pipeline triage: sort scanned images by type, route ID cards one way and invoices another, tag a batch of paperwork photos before OCR. Compared to the pack's food and age classifiers, this one has actual production utility for anyone dealing with paperwork - it's the difference between a toy and a tool, and this is the tool.

The caveat is the same one that runs through every node in this pack's classifier family: no model card is exposed in the README, so you don't know exactly which classes the model was trained on until you run it. Your first task is discovery - feed it your own documents and see what comes back, because a model trained on Western receipts will be confused by an invoice format it's never seen. Test on your actual document types before you trust it in a pipeline.

Install and notes

Pack install, once: ComfyUI Manager → search "ComfyUI-LexTools", or git clone https://github.com/SOELexicon/ComfyUI-LexTools into custom_nodes, restart. transformers required; model downloads from HuggingFace on first use.

And a practical note for a node in a pack that's seen very little community activity: don't assume the class list covers your niche document type. The confidence signal is decent on the common classes and worthless on unseen ones - a document type the model wasn't trained on will get labeled as whichever known class it resembles most, with full confidence. That's not a bug in the node; it's the nature of closed-set classification, and it's why discovery runs matter.