Jump to the page text

PaidSmith

How to get an invoice paid

3 MyCase time entry fields to check before a LEDES invoice

PaidSmith Editorial Team · Published · 13 min read

Why these three fields matter

Check the case link, user, and decimal time fields in MyCase before you build a LEDES invoice. A LEDES invoice is a data file, not a freeform document. TimeSolv describes LEDES billing as the Legal Electronic Data Exchange Standard, "a standardized, machine-readable way to structure legal invoices" ( TimeSolv). Instead of a freeform PDF, the invoice follows a defined format with required fields and coded line items that make review and approval faster ( TimeSolv).

That structure helps, but it also means a machine reads your data. A value that is blank, typed in the wrong form, or tied to the wrong record can get a file flagged, even when the legal work behind it was done well. The number of hours is rarely the only problem. More often, a field does not match what the reader expects.

The LEDES Oversight Committee keeps a published list of error codes. In version 2, it identified 65 unique errors that could apply to any of the fields in the various LEDES billing formats ( LEDES Error Codes). The committee ratified version 1 in 2020. The work continued in 2022, when the codes were expanded to include tax errors and additional common errors encountered across client implementations ( LEDES Error Codes).

You do not need to memorize those codes. The time entries you record in MyCase are the raw material for the invoice, so the practical question is simpler: which fields on each entry could be wrong, and how would you find out before the client does? The three fields below are the ones to check first.

MyCase's help article defines the field in one line: "Case Link - Specify the case/matter that the time entry should be associated with." ( MyCase Help Center) The line is short, but the field carries a lot of weight. If an entry points at the wrong matter, the hours land on the wrong client's bill. The invoice can still look tidy to you, which is why this mistake is easy to miss.

The same article explains where entries start. To create a new time entry, click Create Time Entry on the Quick Actions Dashboard ( MyCase Help Center). Set the case first, before you write the description or enter the hours. Filling in the case first is a habit that keeps a blank or wrong matter from slipping through while you are focused on the work itself.

Several things go wrong with case links in small firms:

  • Two matters have similar names, such as an original dispute and a follow-on matter for the same client, and the entry lands on the wrong one.
  • A matter was renamed or closed, and nobody checked whether recent entries still point at the right one.
  • A new entry was copied from the last one, so the new work sits under an unrelated matter.

Before you generate an invoice, sort or group your entries by case and read the list from top to bottom. A matter you did not expect to see on a client's bill is the fastest sign of a mistake. If a case looks wrong, confirm with the person who did the work before you change it. That one conversation can prevent a correction on a bill that has already gone out.

Entries that get moved need the same care. If an entry was recorded on the wrong matter and you move it, read the note again. A note that describes a different document or call can cause as much trouble as a wrong case number, because the description now belongs to a matter it does not match.

Field 2: User

The User field tells the system which firm user a time entry belongs to. MyCase describes it this way: "User - Specify the firm user that the time entry should be associated with." ( MyCase Help Center) In a small firm, this is the field that ties the work to a specific person. It matters most when more than one person touches the same matter, because each person's entries need to name the right author.

The most common mistake is recording time under whoever was logged in, rather than whoever did the work. Consider a paralegal who spends an afternoon on a deposition summary for an attorney. If they save the entry under their own name, the work is attributed to the wrong person. The amount of time may be right, but the record of who did the work is not.

The opposite mistake happens too. An attorney who reviews a draft and then asks an assistant to log the review may end up with an entry tied to the assistant's login. Nobody did anything dishonest. The habit simply went unchecked.

User records also go stale. Someone who has left the firm, moved to a different team, or stopped working on a matter may still be attached to entries they no longer should own. When you find those, confirm with whoever administers the firm's MyCase account before you reassign anything. A quiet edit can leave a record that nobody can explain later.

Checks to make on the User field:

  • The user on each entry is the person who performed the work described in the note.
  • Entries logged on someone else's behalf are attributed to the person who did the work.
  • On a shared matter, every person who billed has entries under their own name.

A quick test helps. Pick three entries at random each week and ask the person who did the work whether the User field is right. Three checks take a few minutes, and they catch a pattern early, when it is one habit to fix rather than dozens of entries to correct.

Field 3: Time, entered as decimal hours

MyCase's time tracking article gives a direct example of how to enter a duration: "For example, six minutes would be entered as '.1' and 30 minutes would be entered at '.5'." ( MyCase Help Center) The time is entered as a decimal fraction of an hour, not as minutes and not as an hour-and-minute reading. Converting is simple, but this is the field where the most small typing errors happen.

Using the same arithmetic as that example, a few common durations look like this:

  • 6 minutes: .1
  • 12 minutes: .2
  • 30 minutes: .5

Three mistakes show up again and again:

  • Hours and minutes typed as a decimal. Writing an hour followed by the minutes, as if they were digits after a point, gives a value that reads as a different amount than the decimal fraction of an hour. Decimal hours carry the fraction of an hour directly, so an hour and a half is entered as one and a half in decimal form, not as an hour followed by the minutes.
  • A misplaced decimal point. Typing 5 instead of .5 multiplies the time on that line by ten. A five-hour entry for a half-hour call is easy to overlook in a long list, especially when the rest of the list looks normal.
  • Partial increments. Six minutes is .1 in MyCase's example. For time that falls between your increments, your firm's rounding practice and the client's billing guidelines decide the value. Check them before you start entering time, not after an invoice is flagged. For rounding options, see Billable time rounding: 3 modes for invoices.

Read each day's total against what you remember of the day. If a day made up mostly of short calls shows one very large line, something is wrong with that line. Catching it at this stage takes seconds. Catching it after the invoice is generated takes much longer.

Check bulk entries row by row

The bulk option lets you log several entries at once. The help article describes its limit this way: you "can create a total of 50 bulk time entries by adding 5 more rows as you go" ( MyCase Help Center). For more on tracking several time entries, see Track multiple time entries: 5 legal software tools.

Speed is one reason to use it, and speed is also the reason mistakes slip in. A row copied from yesterday can carry yesterday's case, the wrong user, or a time value you did not intend. The three fields are easy to skim when you are entering many lines at once, and one wrong case can quietly spread down a list.

Rules that help with bulk entry:

  • Read every row's case, user, and time before you save, not just the first and last rows.
  • Watch the row count. If you have more entries than the 50-row total allows, split them into batches and check each batch on its own.
  • Do not assume a row is right because the row above it was. Copied rows repeat their mistakes.

Clean up as you go

The easiest time to check an entry is when you make it. Waiting until the invoice run means checking dozens of entries at once, and a long review is easy to rush. A few habits make the difference:

  • Fill in the three fields in the same order every time: case, then user, then time.
  • Enter the time as a decimal as soon as you have it, rather than converting from notes later.
  • After saving, read only the three fields once before you move to the next entry.
  • Write a clear description for each entry, so a reviewer can tell what the work was without asking.

None of these habits takes long. Together they mean the review before the invoice is a check, not a rescue.

Set a cutoff before the invoice run

A cutoff is a simple fix for a common problem: entries that arrive after the review has started. Pick a point in each billing cycle after which new entries wait for the next run, or after which you review them separately. Without a cutoff, late entries slip in unchecked, and the person building the invoice cannot tell which lines were reviewed.

The cutoff does not need to be elaborate. A note in the firm's calendar, a reminder to the people who enter time, and a single person responsible for the final check are enough for most small firms. What matters is that the same rule applies every cycle, so the review covers the same set of entries each time.

Late entries deserve their own check. A line added at the last minute is more likely to have been typed quickly, and it is also the line most likely to be missed if the review has already been done. Read the three fields on any late entry before it joins the batch.

A worked example

Here is a hypothetical week for a three-person firm. A paralegal and an attorney work on two matters for the same client, and an assistant helps with logging. Each person is supposed to enter their own time, though in practice the lines blur.

The paralegal spends the morning on a discovery request for matter A. The case link is matter A, the user is the paralegal, and the time is two and a half hours, entered in decimal form. The paralegal also spends an hour on a call with the client about matter B. That entry goes to matter B under the paralegal's name, with a note that they attended.

The attorney reviews the discovery draft for 30 minutes, which is .5 in MyCase's format. They ask an assistant to log it for them. The assistant enters the time, but the User field names the assistant. Nothing about the review changed, but the entry now credits the wrong person.

When the firm does its review, three things come up. Grouping by case shows matter A and matter B, which is what the firm expected. Checking the user on each entry catches the review that names the assistant, and the fix is to change the user to the attorney. Reading the decimal hours one at a time catches a second problem: the discovery entry was typed with its decimal point dropped, which multiplies the time on that line by ten. That is the kind of error that would have stood out on the invoice.

The fixes take a few minutes in MyCase. Skipping them could mean a rejected file, a confused client, or a correction after the bill has already gone out.

One error, many rows

The LEDES Error Codes page gives a useful example of how a field can cause repeated problems: "As an example, the XML field @FIRM.lf_vendor_ID and the ASCII field LAW_FIRM_ID appear in rows 8 through 21 and are associated with 7 unique error codes across 14 rows." ( LEDES Error Codes)

That example is about firm identifier fields, not the three MyCase fields in this post. The lesson still applies. A field can repeat across many rows, and one wrong value can trigger several codes in several places. A wrong case or user on one entry is usually wrong on the copies made from it, so the same mistake can show up again and again.

Fixing the entry once, at the source in MyCase, is faster than trying to repair every line that carried the same mistake. It also keeps the next export from inheriting the problem. Patching a file by hand may clear one flag, but the cause stays in the entries.

A review routine before you send

Make this routine a habit, and run it at the same point in every billing cycle:

  1. Group entries by case, and confirm each matter is one the client actually instructed you to bill.
  2. Check the user on each entry against the person who did the work.
  3. Read the decimal hours one at a time, and flag any value that looks ten times too large or too small.
  4. Check the daily totals against what people remember of their days.
  5. Confirm any bulk entries row by row, not by scanning.
  6. If the file is rejected, read the error it gives. Match the error to the field it names, fix the entry in MyCase, and rebuild the file.

Who does the review matters too. A person who did not enter the time often catches what the author misses. If your firm is too small for a second reader, schedule a short weekly review with a colleague or a bookkeeper who can look at the entries with fresh eyes. For a fuller sign-off list, see Invoice approval checklist: 6 checks for billing teams.

When a file is rejected

A rejected file is not a disaster. Start by noting the error code and the field it refers to. Then check the same field on other entries from the same batch, since one cause often repeats. The LEDES Error Codes page is the reference for what each code means, and it is the first place to look when an error is unfamiliar.

Automated tools can help too. TimeSolv notes that "using automated billing tools simplifies the creation of these complex files and reduces invoice rejections" ( TimeSolv). A tool does not fix bad inputs, though. It applies its logic to whatever data you give it, so clean entries are still the first step.

Keep a short log of rejections with the date, the code, the field, the cause, and the fix. Within a few billing cycles, you will see patterns, such as the same user field going wrong or the same kind of decimal error. A pattern tells you which habit to change, and that change does more good than fixing each rejection on its own.

Keep the three fields honest

Three fields carry most of the risk on a LEDES invoice: the case link, the user, and the time in decimal hours. Check them on every entry, not only the ones that look unusual. Use the bulk option carefully, read each row, and build a short review step into every billing cycle.

Start with one habit this week. Pick the field your firm gets wrong most often, check it on every entry until the mistakes stop, and then add the next field. Small, steady checks work better than one large cleanup before each invoice.

The invoice is only as clean as the entries behind it, and the entries are where a small firm has the most control. A few minutes of checking in MyCase is far cheaper than a rejected file, a confused client, or a correction sent after the bill has gone out.

Sources