A proposed workflow practice for small bilingual tax offices: record a document's state before asking for it again, and write the follow-up complete in the client's language.
Two versions of the same missing document
Two people can look at the same missing document and hold different pictures of it. A client uploads a photo Tuesday night and assumes the office has it. A staff member sends a reminder Thursday because nothing in front of them says it arrived.
The reminder is not careless. It is written from a different picture of the same file. A client may read it as a sign that the upload failed, or that nobody looked, and the office may read the silence that follows as a client who has not sent anything.
Neither person is acting in bad faith. They are working from separate records of the same fact, and no message in the thread reconciles them.
Check the state before you send the request
The practice is a small one: before sending another request for a document, record and check that document's current state, then write from what the record says.
It changes the order of two steps. Whether existing tools can support it comes down to one question: can they keep an authoritative status record in one place and limit who can change it.
A status is itself information about a client. That a person has an open file, and that a particular document is outstanding, is something to keep visible only to the roles whose work requires it.
What the record has to hold
A useful record does not need many fields. It needs enough that a second person can read it and act without asking the first.
- the document, named the way the client would recognize it
- its current state
- when the state last changed
- who changed it
- what the office is waiting on next, in one line
When status is tracked in free-text notes, the current fact can end up inside a longer history that the next person has to read through. Keeping the state in its own field is intended to make it checkable at a glance.
Two additions are worth thinking twice about: anything that duplicates a fact the practice system already owns, and anything that copies document contents into a place with wider access than the document itself.
Let the office define its own states
The states belong to the office. As an example for discussion, an office might work with three: received, still needed, and ready for office review.
These are placeholder labels. They are not a taxonomy from any agency, not a fixed set of product states, and not a recommendation about how many states an office should keep.
An owner would replace them with words that match the real process, and would decide:
- which states exist, and what each one means in a single sentence
- who is authorized to move a document from one state to another
- what evidence is required before a state changes
- what happens to a document that sits in one state longer than expected
Offices that already track this informally, in a shared inbox or a spreadsheet column, are describing states already. Writing them down mostly makes the vocabulary consistent between people.
What "ready for office review" has to mean
Of the three, this label needs the narrowest definition, because it is the one most easily overread.
It means one thing: the document has reached the point where the office's next review step can begin.
It does not mean the document is complete. It does not mean it is accurate, legible, current, approved, prepared, or ready to file. Those are separate determinations, made by qualified people, on their own schedule.
If staff and clients can both see the label, the wording carries more weight. "Ready for office review" describes a position in a queue. A label such as "done" or "complete" may lead a reader to conclude something about the return itself.
One action per state
A state earns its place when it tells the person reading it what to do next and, just as clearly, what not to do.
The matrix below is an example to adapt. Each row pairs a state with the action that follows it and with the message that would go out, if any.
The third column is there for restraint. When a document has already been received, the intended outgoing message is often none.
Before you hit send
The list below is meant to sit at the moment of sending rather than in a separate procedure document, so the check stays attached to the action it belongs to. It is a starting point for an office to cut down or extend.
The follow-up message itself
When a request does go out, two things belong in it: where the document stands, and the one action being requested.
Write the message in the client's language, not as an English message with a translated fragment appended. A message assembled from two languages can leave the reader working out which part is authoritative.
One request per message is a related discipline. A message listing four outstanding items and two questions may ask the reader to sort before they can act.
The intent is to make the requested next action explicit. Whether that changes how quickly or how well anyone responds is not something this package measures or claims.
A separate obligation that runs alongside all of this
Whatever an office decides about labels and messages, its responsibilities for handling customer information continue unchanged.
IRS Publication 4557 is educational guidance for tax professionals on safeguarding taxpayer data. The passages referenced here are drawn from the text supplied to and verified for this package.
This project's source list also names the FTC's Safeguards Rule overview, the corresponding regulation at 16 CFR Part 314 (eCFR), and the NIST Cybersecurity Framework as background material. None of the three was supplied as verified text for this stage, so no specific provision, exemption, or requirement from any of them is stated here as established fact. Verifying those three sources, and deciding whether to cite them, remains open for a later stage that can access and confirm them.
The included, truncated Publication 4557 text reviewed for this package contains no discussion of status labels, follow-up wording, or language choice. It is cited here only for the surrounding duty to safeguard taxpayer data through a written security plan, access controls, audit trails, and related protections.
Where this leaves Intaxion
In this package, Intaxion is positioned as a complementary layer around the systems an office already uses: intake, document gathering, follow-up, communications, and review readiness.
That is the positioning boundary the owner set for this material, not a verified account of how the product behaves. The same boundary rules out positioning Intaxion as tax preparation or filing software, or as a security, translation-validation, legal, or compliance product.
Which capabilities can be stated as fact still has to be checked against current product material.
What a person still has to decide
Some of this cannot be settled by writing about it:
- the status vocabulary that matches the office's actual process, in both languages
- who is authorized to change a state, and what they need to see first
- the Spanish regional register the office's clients expect, assessed by a qualified person
- how the Safeguards Rule applies to the firm, assessed by qualified counsel
- which Intaxion capabilities may be described as fact, and against which current product material
- whether the FTC Safeguards Rule overview, 16 CFR Part 314 (eCFR), and the NIST Cybersecurity Framework should be verified and, if appropriate, cited in a later stage
- whether the internal bilingual route paths below match the site actually in use for this project, pending confirmation
Nothing in this article resolves those points. They are listed so a reader can see what is still open.
Sources
- IRS Publication 4557, Safeguarding Taxpayer Data: https://www.irs.gov/pub/irs-pdf/p4557.pdf
It is cited only for the duty to safeguard taxpayer data through a written security plan, access controls, audit trails, and related protections. This project's source list also names the FTC Safeguards Rule overview, 16 CFR Part 314 (eCFR), and the NIST Cybersecurity Framework; none of the three was supplied as verified text for this stage, so none is quoted or cited as a source here, and no specific provision from any of them is asserted as fact. No page numbers, section titles, quotations, or statistics are asserted beyond what the supplied material established.
- https://www.irs.gov/pub/irs-pdf/p5708.pdf
- https://www.ftc.gov/business-guidance/resources/ftc-safeguards-rule-what-your-business-needs-know
- https://www.ecfr.gov/current/title-16/chapter-I/subchapter-C/part-314
- https://www.nist.gov/itl/smallbusinesscyber/nist-cybersecurity-framework-0
Get our free Tax Preparer Compliance Checklist
A practical checklist to ensure you're meeting all IRS due diligence requirements. Download instantly.
We respect your privacy. Unsubscribe at any time.