1099 & tax filing—from a payment to an IRS acknowledgment
A return can be perfectly formed and still be rejected.
Arcvue Tax Filing carries a vendor payment through 1099-NEC determination, the IRS schema and an acknowledgment, keeping what you may bill separate from what you must report. This page follows Arcvue filing one 1099-NEC through nine steps.
Synthetic. An invented vendor. The $840.00 you may not bill the government is money you still paid—so it is disallowed under one regime and reportable under the other, in full. Allowability and reportability are different questions about the same dollar, and a system that conflates them gets one of them wrong.
Specimen Systems LLC · an example 120-person contractor · all figures synthetic
A subcontractor crosses two thousand dollars, and from that moment a return is owed.
Nothing is inherited yet. Payments accumulate against a vendor across a calendar year, and at $2,000.00 the obligation attaches—not at year end when somebody runs a report, but at the payment that crossed it. This vendor is at $198,400.00, which is $196,400.00 past the line.
The obligation exists whether or not anybody is tracking it, which is the whole difficulty. In most firms the first anyone thinks about 1099s is January, at which point the question is archaeological: who did we pay, how much, and do we have what we need to report it.
What this page counts. Not whether the form gets produced—producing a PDF is easy. What could still make it unacceptable when it reaches the IRS, and what Arcvue does about each one.
The vendor you cannot report is flagged in July, not discovered in January.
The obligation from stop 01 needs a taxpayer identification number, and the document that supplies it is a W-9 you were supposed to collect before you paid anybody. A reportable vendor with no W-9 on file is the single most common reason a January filing season becomes a fortnight of chasing.
So it is a standing surface rather than a year-end query: vendors past the threshold with no W-9 on file, listed as they cross it. A vendor you are still paying answers the phone. A vendor whose last invoice was in March, whose contact has left, and whom you now need a signed form from in the second week of January, does not.
A taxpayer number is only correct in combination with a name, and the pair travels together from the moment it arrives.
The W-9 from stop 02 supplies a name and a number. Neither is meaningful alone: the IRS matches them as a pair, and a return where they disagree comes back as a notice months after filing, at which point correcting it involves the vendor, the IRS, and a deadline that has passed.
The failure mode worth naming is not a wrong number. It is a payment credited to the wrong vendor—the same silent-misattribution class as crediting one payment to two different returns. It produces books that balance and returns that are individually well-formed, which is exactly why nothing catches it downstream.
The money you could not bill the government is money you still paid, and all of it reports.
With a matched pair from stop 03, the amounts can be placed. The bill the accounting page follows carried $24,710.00 of subcontract labor, $1,200.00 of travel, and $840.00 for a client dinner that was coded unallowable under FAR 31.205-14.
Box 1 of the 1099-NEC is $26,750.00—the whole invoice. Allowability governs what you may charge a customer; reportability governs what you tell the IRS you paid a vendor. They are different regimes asking different questions about the same dollar, and a system that lets one answer the other will report too little.
Which box is a real decision, not a form-picker. Arcvue files the 1099-NEC, and the box an amount lands in comes from how the payment was coded when it was made—settled in June by the person who knew what the invoice was for, rather than reconstructed in January by somebody reading a vendor name off a report.
A perfectly valid document can be rejected, and validity was never the question.
Well-formed is not the same as acceptable.
Everything through stop 04 produces a return that is correct in its own terms. Schema validation will confirm it: every element present, every pattern matched, every enumeration legal. And schema validation says nothing whatsoever about whether the IRS will accept it.
On top of the schema sit the IRS business rules—consistency between counts and contents, manifest indicators that must agree with the records they describe, uniqueness constraints, and value rules a schema cannot express at all. A return can pass schema validation cleanly and still break a dozen of those business rules.
The usual way to find out which dozen is to transmit, be rejected, read the rejection, fix it and resend—learning the rules by collecting refusals, one filing season at a time. Stop 06 is what Arcvue does instead.
The rules that can be decided from the transmission alone are decided before it leaves.
Stop 05 named the gap; this closes the part of it that can be closed locally. Some of those rules depend on nothing but the document in front of you—whether the stated record count matches the records present, whether a manifest's form indicators agree with what it contains, whether identifiers are unique within the transmission, whether a state named for combined filing actually participates in the program.
There are twenty-eight of those, and Arcvue runs every one against the transmission before it is sent. A rejection caught here costs nothing. The same rejection in the last week of January costs days you do not have.
And here is what Arcvue deliberately does not check.
“We validate against the IRS business rules” would overclaim badly, so this page says which ones and which not. Twenty-eight rules run before every transmission. Four classes do not run, and all four are named below.
| Class of rule | Checked here | Why |
|---|---|---|
| The manifest—the transmission's own header against what it carries | Yes · 7 | The software id bound to the tax year, the control code inside the transmission id, the channel marker that terminates it, the prior-year and original-transmission indicators, and a real transmitter EIN rather than a test one |
| The transmission as a whole | Yes · 8 | Stated counts against the records actually present, manifest form indicators against the records they describe, identifiers unique within the transmission |
| The payer and the 1099-NEC record itself | Yes · 13 | The value rules a schema cannot express—a state named for combined filing has to actually participate in the program, a test file's recipient numbers have to start 000, amounts and indicators have to agree with one another |
| Database-match rules | No | They compare a name, a number, or a filer registration against the IRS's own records. Nothing local can answer them, and pretending otherwise would be worse than silence. |
| Prior-transmission rules | No | They reference a submission the IRS previously accepted |
| Forms Arcvue does not file | No | Checking rules for returns we never produce would be theater |
| Anything the schema already enforces | No | A second implementation of an enumeration only ever disagrees with the first |
Screen Arcvue IRIS business-rule checks, scope as implemented. Read this one row by row. Seven classes of rule. The counts are rules implemented against the IRS's own published business-rule package, and a violation reports under the IRS's rule identifier rather than one of ours. Why publish it. A compliance claim you cannot bound is a compliance claim you cannot keep. The rows marked No are the ones a customer most needs to know about, because they are where a rejection can still come from—and a vendor who lists them is telling you where to look. Synthetic sample.
Transmission returns one identifier, and losing it is the expensive mistake.
A transmission that has passed stop 06 leaves over an authenticated application-to-application channel—signed assertions, short-lived access tokens, the document posted as XML. What comes back is a receipt identifier, and it is the only handle you will ever have on that submission.
Transmitting to the IRS is a per-filer permission, for every vendor and every filer—so your firm is provisioned as a transmitter once, during onboarding, and the channel above is the one your returns then travel on. It is a step in getting you live, done once, before your first season.
The IRS's own guidance is to guard it against loss, which is a strong hint about how often it is lost. So Arcvue stores it as a record against the filing rather than printing it into a log. Logs rotate. The question it answers—was this return ever received—is asked long after that.
A submitted return is not a filed return.
Which is what the obligation at stop 01 has been waiting for.
A receipt proves the IRS took delivery. It does not prove they accepted anything. The submission is polled for an acknowledgment, and until that comes back the correct internal state is submitted—not filed, and certainly not a green tick. That is how the state machine is built.
That distinction is the whole page in one line. The obligation attached at stop 01 when a payment crossed $2,000.00; it is discharged by an acknowledgment and by nothing else. A dashboard that marks a return complete on transmission is reporting its own action rather than the outcome—and the difference between the two is a season's worth of corrections nobody knew were needed.
Read the trail backward and it holds. From the acknowledgment to the receipt, to the rules that passed before it was sent, to the box the amount landed in, to the matched name and number, to the W-9 collected in July, to the payment in March that crossed the threshold. Nine steps, and the first one happened ten months before anybody thought about tax.